feature enhanced_re_xx

[khwilliamson]

No description provided.

[rjbs]

@khwilliamson This sort of slipped through the cracks. Shall we discuss its future?

[khwilliamson]

On 9/23/22 08:36, Ricardo Signes wrote: @khwilliamson <https://github.com/khwilliamson> This sort of slipped through the cracks. Shall we discuss its future? — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA2DH3XTNKATUM6VUHXI23V7W6ALANCNFSM5XCRZ5SQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

Sure

[hvds]

I don't know if I responded to this before, perhaps during p5p discussion.

I am concerned about having multiple /x-style variants - I do not think we should have more than one. So I think it would be better to make this an opt-in change to how /x is interpreted (with the aim that it eventually may become a 'use v5.xx' default), and aim to retire /xx.

But I think it is also important that we avoid continued passes at this, because of the knots we tie ourselves into to preserve backward compatibility: let's make sure we've fully specced what the ideal /x grammar should look like, and if there are any aspects of that we cannot implement right now, let's think about whether we can retain space to add them in the future (or even whether we should choose to defer changes until we can implement the full thing).

In that respect:

• what counts as whitespace we want to ignore?
• where in a pattern (if anywhere) should whitespace not be allowed?
• what counts as a comment we want to ignore?
• where in a pattern should comments not be allowed?

[hvds]

@rjbs duplicating here, since you presumably did not see my email

While our RFC process was a bit more wobbly, Karl propose an enhanced form of /xx for regex #17. I have included the text below so we can discuss it on list. I will reply to this post with some comments.

I had commented on the pull request, apparently around the same time as you sent email to the list. Should I duplicate the comment for the discussion on-list?

I confess I don't understand where these discussions are supposed to happen, or how one should know when the venue has changed.

[khwilliamson]

On 10/7/22 11:26, Hugo van der Sanden wrote: @rjbs <https://github.com/rjbs> duplicating here, since you presumably did not see my email While our RFC process was a bit more wobbly, Karl propose an enhanced form of /xx for regex #17 <#17>. I have included the text below so we can discuss it on list. I will reply to this post with some comments. I had commented on the pull request, apparently around the same time as you sent email to the list. Should I duplicate the comment for the discussion on-list? I confess I don't understand where these discussions are supposed to happen, or how one should know when the venue has changed.

I'm told to use "substantive discussion on p5p, copy editing on GitHub" Since /xx has been in effect since 5.26, I see no feasible path to folding it and plain /x together.

[hvds]

On 10/7/22 11:26, Hugo van der Sanden wrote: @rjbs https://github.com/rjbs duplicating here, since you presumably did not see my email While our RFC process was a bit more wobbly, Karl propose an enhanced form of /xx for regex #17 <#17>. I have included the text below so we can discuss it on list. I will reply to this post with some comments. I had commented on the pull request, apparently around the same time as you sent email to the list. Should I duplicate the comment for the discussion on-list? I confess I don't understand where these discussions are supposed to happen, or how one should know when the venue has changed.
I'm told to use "substantive discussion on p5p, copy editing on GitHub" Since /xx has been in effect since 5.26, I see no feasible path to folding it and plain /x together.

The path is straightforward, and similar to what you propose here: introduce the change under a feature, intending to make the feature default within the lexical scope of an appropriate use v5.xx declaration after a period of bedding-in.

[khwilliamson]

On 10/12/22 16:54, Hugo van der Sanden wrote: On 10/7/22 11:26, Hugo van der Sanden wrote: @rjbs <https://github.com/rjbs> https://github.com/rjbs <https://github.com/rjbs> duplicating here, since you presumably did not see my email While our RFC process was a bit more wobbly, Karl propose an enhanced form of /xx for regex #17 <#17> <#17 <#17>>. I have included the text below so we can discuss it on list. I will reply to this post with some comments. I had commented on the pull request, apparently around the same time as you sent email to the list. Should I duplicate the comment for the discussion on-list? I confess I don't understand where these discussions are supposed to happen, or how one should know when the venue has changed. I'm told to use "substantive discussion on p5p, copy editing on GitHub" Since /xx has been in effect since 5.26, I see no feasible path to folding it and plain /x together. The path is straightforward, and similar to what you propose here: introduce the change under a feature, intending to make the feature default within the lexical scope of an appropriate |use v5.xx| declaration after a period of bedding-in.

To clarify my point. The path may be straight forward, but we would discover that too much existing code would have to be changed. I found this out with trying to make unescaped '{' warn. I had to narrow the scope significantly to just the contexts where it really mattered. People put blank and '#' in bracketed character classes all the time., We really have to have a different modifier to indicate the new way of doing things.

[hvds]

The path is straightforward, and similar to what you propose here: introduce the change under a feature, intending to make the feature default within the lexical scope of an appropriate use v5.xx declaration after a period of bedding-in.

To clarify my point. The path may be straight forward, but we would discover that too much existing code would have to be changed.

That existing code presumably does not declare use feature qw{groovy_regexps} nor use v5.44, why would it have to change?

[khwilliamson]

@hvds , my goal is to have /xx work this way eventually without having to opt in.
I didn't understand what you were suggesting, that it always be opt-in, and use plain /x. Requiring opt-in means no need for deprecations, etc.