Re: qr//xx in 5.26?

On 01/09/2017 05:51 AM, Karl Williamson wrote:
> 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?

Ah I see. My bad.

Then yes, I believe we can indeed use it in 5.26. I don't think we need
to fatalize before removing or re-purposing.

If we don't have anything to do with it *yet*, then we can make it
produce an error after two cycles of warning.

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

Thanks for the clarification. :)

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

That seems reasonable to me.

• 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