Front page | perl.perl5.porters |
Postings from December 2017
Sawyer X wrote: >This is simpler to resolve. We can allow subroutine attributes before >and after. No, that's not a simple resolution. If attributes are allowed in both places, then it's still possible for a :lvalue attribute to come after a signature, incurring the same problem that arises now. This would need to be addressed in some way. To just let it compile incorrectly would be crap. To be less crap we'd have to enforce the :lvalue attribute going before any signature, which would mean the core knowing which attributes have to go before the signature and to check for them. This would be a significant extra complication, in API as well as implementation, in the likely event that we later want to apply non-core attributes early enough to affect body compilation. Any way round, we'd also have to document which attributes have to come before the signature and which are allowed in both places. We'd be demanding that users know about this specific interaction, rather than just being able to compose orthogonal features. Any version of this constitutes an argument, of some strength, that signatures are still failing to play nicely with an existing stable feature, and that they impede likely future developments, and therefore that they can't qualify as a stable feature. It is not sufficient to merely make it *possible* to combine a signature with an lvalue sub. -zeframThread Previous | Thread Next