* Sawyer X <xsawyerx@gmail.com> [2018-01-14T05:01:05] > On 01/13/2018 10:26 PM, Ricardo Signes wrote: > > I always assumed that signatures would end up living in a versioned bundled. > > (something we could fix if we disambiguate signatures syntax from prototype > syntax) I think that having this behind "use v5.x" is just fine, and not something to fix. Among other things, it is a nice nudge to put a version requirement in one's code! * Sawyer X, previously, edited: > * The only way to support prototypes that affect signature compilation > (such as lvalue prototype) is by allowing [attributes] on both sides. I do > not find the ability to put signatures before [attributes] a compelling > enough reason for the work requires to support [attribuets] on both sides. > also think it would create inconsistencies where some code would be > written with [attributes] after and some with [attributes] prior. Instead, I > think we will resolve to moving signatures again to be after [attributes]. If this is fixing a real problem, as I get the impression it is, then it seems reasonable. My initial objection was that all things being equal, I expected users to think "sub NAME ARGS" go in just that order, as is traditional, and that attributes, the weird thing, could most easily be added as the end. I think there was general, though not unanimous, agreement from attribute users. The argument against, at the time, was an appeal to consistency that didn't sway me. "Putting them there will break features" is more convincing. The other option is "you can't have signatures and some subset of attributes." Seems like a pain. -- rjbsThread Previous | Thread Next