Re: qr//xx in 5.26?

On 01/08/2017 12:33 PM, Sawyer X wrote:
>
>
> On 01/05/2017 11:20 PM, Karl Williamson wrote:
>> We never have really discussed what happens when we deprecate
>> something in order to use the construct for something else.
>
> I don't see why it needs to be any different than a regular deprecation
> cycle.
>
>>
>> After 2 deprecation cycles can we just re-use it?  Or do we need 1 or
>> 2 additional cycles where its attempted use generates a syntax error?
>
> What makes sense to me is two versions of deprecation warnings, and the
> next version allows re-purposing.
>
>>
>> In particular, qr//xx has generated an error since 5.25.1.  There have
>> been no reports of problems as a result.
>>
>> Is it ok to give /xx its new meaning in 5.26? or should it generate an
>> error for 5.26, and we defer changing it until 5.27?
>
> I think it's fortunate this did not raise any issues, but I'm not sure
> why this means it doesn't need two release cycles of deprecation. I
> admit this particular one is different in the sense that this is
> something that until now was just not used. You couldn't do anything
> with /xx before, so we're not deprecating an existing feature, just
> tightening up when we find it. That might be different enough to not
> fall under the policy. What do you think?

You misunderstand.  It was deprecated starting in 5.22, and starting in 
5.25 its use generates an error.  My question was, are those 2 cycles 
sufficient, so that 5.26 can be shipped with its new behavior, instead 
of an error?

/xx is an existing feature, just as /xxx or /xxxx are.  All are treated 
as if there were only one /x specified.  But starting in 5.22, using 
more than one has generated a deprecation warning.  For those of you who 
don't remember, /xx is intended to extend /x behavior to within [...] so 
that blanks can be used for readability there, but a blank intended to 
be a literal will have to be escaped.  A blank is either one of 2 
characters: SPACE and HORIZONTAL TAB.  So this is changed behavior for 
bracketed character classes.

>
>>
>> And there needs to be some policy in general for this situation.  For
>> example, the decision might be different for the unescaped left brace
>> deprecation, which has caused lots of problems in 5.25.
>
> True.
>

I believe it needs to explicitly say then that after 2 deprecation 
cycles, the feature can be repurposed, with possible exceptions based on 
individual cases.

• qr//xx in 5.26? by Karl Williamson
• Re: qr//xx in 5.26? by Sawyer X
• Re: qr//xx in 5.26? by Karl Williamson
• Re: qr//xx in 5.26? by Sawyer X