develooper Front page | perl.perl5.porters | Postings from March 2020

Re: chained comparisons

Thread Previous | Thread Next
Sawyer X
March 12, 2020 22:54
Re: chained comparisons
Message ID:

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 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 

[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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About