Front page | perl.perl5.porters |
Postings from March 2020
Re: chained comparisons
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
March 12, 2020 22:54
Subject:
Re: chained comparisons
Message ID:
6b7ca25b-7b9e-a8b5-26ce-6edf16eb6a10@gmail.com
On 3/7/20 10:41 PM, Zefram via perl5-porters wrote:
> Leon Timmermans wrote:
>> 1. Does it need to be a feature? (in the feature.pm sense of the word)
> No, for the reason you stated. This is also the same reason why,
> without a feature flag, it's compatible with the current freeze status.
I agree with both of these statements.
>
>> 2. Does it need an experimental warning?
> No, it's not experimental. The semantics are obvious and dictated by
> the existing operators; there's really no possibility of tweaking them.
This also seems correct to me.
> The question is not what this feature should look like, but merely whether
> we want to implement this feature,
I'm not so sure about this though.
I've thought of Karl's arguments and initially thought putting this
behind experiment makes sense. Now I'm not so convinced.
Do we imagine the semantics changing? No.[1]
Do we imagine this becoming a security concern? I don't think so.[2]
What I am wondering is how far can these semantics be stretched. I
honestly doubt if that far, since this seems like such a well-scoped
syntax change.
> and we are already well placed to
> make a firm decision on the matter.
I agree we are well placed to make a firm decision on whether we want to
implement it, but not whether we need to guard it with an experimental
warning.
[1] There were many things we didn't expect to change semantics, but
they did. However, they were fairly large in scope, like signatures,
smart match, etc.
[1] Then again, how often do we look at something and imagine it a
security concern? (Perhaps aside from the regex engine. :)
Thread Previous
|
Thread Next