Front page | perl.perl5.porters |
Postings from January 2017
Re: qr//xx in 5.26?
From: Sawyer X
January 9, 2017 12:04
Re: qr//xx in 5.26?
Message ID: firstname.lastname@example.org
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
>>> 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.
> 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.