Front page | perl.perl5.porters |
Postings from January 2018
Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
January 27, 2018 14:35
Subject:
Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz
Message ID:
0f700b07-5c91-338d-719e-71942e1f2b6d@gmail.com
On 01/27/2018 01:17 PM, slaven@rezic.de via RT wrote:
> Dana Sat, 27 Jan 2018 03:21:32 -0800, xsawyerx@gmail.com reče:
>>
>> On 01/24/2018 09:04 PM, slaven@rezic.de wrote:
>>> [...]
>>>
>>> - What does this change means in terms of usability of signatures? Users
>>> mixing signatures and prototypes must increase their perl prerequisite
>>> from 5.22 to 5.28, which may mean it could be less likely that
>>> signatures are used in the next time. Is this worth for this change?
>> We don't like it, but the alternative is that you have partially broken
>> signatures. If we demand that signatures stay where they are, we are
>> demanding they stay broken when it comes to cooperating with other,
>> stable syntax - namely, subroutine attributes. This is literally broken
>> by design, in that sense.
>>
>> Honestly, I feel this is getting ridiculous. We cannot even change
>> experimental features that were *always* experimental because people
>> already started using it?
> I was just asking if it could be done better (which is probably not a good sign that I have to ask...). So that's the dilemma of experimental features: people should not use them because they can change, or vanish; but without using them possible problems get noticed too late.
Theoretically, yes. But it is assuming on foresight, which we are rarely
privileged to. Abigail's idea of a two-year limit to experimental could
help, but we already use two-year to determine that it's stable.
Let's say we have two years to either determine it's stable (as now) or
remove the feature (per suggestion). One year in, we realize there's a
certain limitation we can fix. Should we fix it? We can't. If we fix it,
we go above the two year limitation for removal. This can keep going, as
in the case of subroutine signatures, where we keep finding something.
The problem is that every time we assume it really is the last. For
example, in this case, we don't want to change subroutine signatures,
just their location. As a structure, they're actually stable. Their
location, however, is problematic.
What we could do is provide a limit that is longer than two years, but
we then limit ourselves to how much we can fix. We have to find all the
problems within a certain time or the feature is gone.
This sits in contrast to the benefit of releasing it as experimental.
Unless we allow it to be used, many errors will not be discovered. The
more it is out there, the more likely we are to be able to spot the
problems.
>
> 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 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. If we were to find a
solution and change it once again, we would hit your second question
again - something that worked a certain way as experimental now has to
change.
Basically, we're damned if we do and we're damned if we don't.:/
Thread Previous
|
Thread Next