On Fri, 22 Dec 2017 05:50:13 +0000 Zefram <zefram@fysh.org> wrote: > 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. At the moment the situation is terrible anyway, because of the way that non-core attributes apply to code, they can't actually apply at compiletime at all. The MODIFY_CODE_ATTRIBUTES interface gets invoked on anonymous subs only on the cloned closures at runtime, and not on the protosub at compiletime, so the ability right now to do any fancy user-defined attributes at compiletime doesn't exist. If core has to special-case its current set of attributes, that's not really making the situation any worse than it currently is. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next