To me, the autodie pragma is about fixing the past. Having to check subroutines for errors is a tiresome process, and inattention to detail rapidly results in bugs. Using autodie gives me a way for subroutines to work the way I feel they should: by throwing exceptions on failure. It's easily applied to existing code in lexically sized chunks, so the past can be fixed one block at a time.
However in order for autodie to be able to fix the past, it can't depend upon it to change. I want to be able to use autodie and not have to worry about if my system has a new or old version of File::Copy, or File::Compare, or DarkPAN::BallOfMud. Even if I could change all those modules, some of them are only in the core. Even if the core releases every three months, it will still take too long for them to reach my clients and my code.
I could provide an attributes interface. It would even look quite elegant, but I'm not sure it can be used for good. If new code is being written, I feel it shouldn't try and cling to the old ideas of returning funny (and easily ignored) values on failure; it should be throwing proper exceptions. An attributes interface helps support the old and crusty ways when writing new code, but doesn't help fix the old and crusty code that's already out there.
I'm very happy with the idea of a separate module that reads subroutine attributes and sets hints appropriately. It should be quite easy to write. However I don't believe that it belongs in the core autodie distribution (and hence ultimately in 5.10.1).
All the best,
| 