Front page | perl.perl5.porters |
Postings from February 2018
On 01/28/2018 11:51 AM, slaven@rezic.de via RT wrote: > Dana Sat, 27 Jan 2018 06:35:49 -0800, xsawyerx@gmail.com reče: >> >> On 01/27/2018 01:17 PM, slaven@rezic.de via RT wrote: > [...] >>> But I found the 1st question in the ticket more important. The now >>> not implemented order "first signature, then attributes" seems to be >>> the natural order for me, and it's possible that this kind of error >>> happens often in future. So can we improve diagnostics, or even >>> support both types of order with some safety net where the order >>> matters (like in the case of lvalue)? >> I agree it is more visually pleasing to see signatures prior to >> attributes. However, that breaks. We had several threads in which I >> provided two options for allowing it to work but both provided a >> hairy, >> fragile solution. > I would like to look into this discussion, but it's difficult to find these threads... Agreed. One was titled "Urgent subroutine signatures problems" from December 13th. Zefram noted this in RT #132141 on September 21st. > well, we really need something like a TIP or PEP process... Agreed. I wrote about such an option in a response to "We need a language design process." on January 1st of this year. > > The only thing which I see as a rationale for the change is the examples in perl5.27.8's perldelta. And the lvalue example there looks quite contrived to me. I've had long conversations with Stevan Little about this, who pushed that there is basically only one use that breaks: lvalue (which is a core subroutine attribute) with a signature that calls "return" in the signature. On the other hand, the syntax with signatures following attributes is quite unfriendly and can also confuse easily with Catalyst. It might actually be better to bite the bullet on this and say "Okay, this one case really doesn't work. If you're using lvalue subroutine attribute, you can't return in the signature." and leave it as the much nicer syntax. Considering that code was in until recently, I deem it okay to move it back one development version after. However, I will not accept this if there is just one person (Stevan) suggesting it. I would like further comments from others - like yourself, providing feedback on it. I'm CC'ing Stevan here and will let him make his claim. > >> I did not provide an answer to your first question >> because I don't think I have a good answer other than what we had >> already discussed. I have also expressed the urgency of these and by >> now >> we have passed the deadline on this change. > What deadline? If there needs to be the choice between meeting a deadline and having a good language definition, I would know what to choose. Theoretically freeze. I tried to signal that in the email I wrote on it. However, in this case we have a bit of leeway moving back, as explained above.Thread Previous | Thread Next