develooper Front page | perl.perl5.porters | Postings from April 2013

[perl #117327] Sequence (?#...) not recognized in regex

Thread Previous | Thread Next
Ricardo SIGNES via RT
April 30, 2013 23:09
[perl #117327] Sequence (?#...) not recognized in regex
Message ID:
On Mon Apr 29 11:13:31 2013, wrote:
> I am confident …

Your confidence fills me with contentment!

> What I am unsure of is if we should, so close to 5.18, be making
> something a syntax error that previously wasn't.

I have thought about this.

Right now, we made an inconsistent behavior stay inconsistent, but different and, I think, worse.

I considered these primary options:

(a) the "just for-Heaven's-sake do it" option

Here, we apply Karl's patch.  This eliminates inconsistency now, but adds more fatal cases.  I 
doubt anyone is strongly opposed to this change… except that it would be getting applied 
during the big scary 5.18.0 code freeze, and we have to consider that if "real code" is relying on 
the behavior of /( ?: abc)/ it has a greater chance of being untested and fixed "in time" if the new 
error is first found (other than blead) in 5.18.0-RC1.

On the other hand, it closes the case on this bug, and it is quite tempting to believe that if any 
code is relying on this very sketchy area of the regex system, it's already a grotesque mess, and 
such code probably doesn't even *exist* anyway.  Unfortunately, such code clearly does exist:

As someone who loathes "just put more whitespace anywhere you like" grammars, I was sad to 
see my name in that list. ;-)  It looks to me like "compressed regex nonsense" is likely to be a 
factor here, which means "stuff breaking that nobody knows why or how or what to fix."

(b) the "don't break backcompat" option

Here, we revert the original change, with a firm plan to fix it thoroughly in the future.  We need 
to issue a notice that the current behavior is going to be corrected, so we do that now.  Then in 
5.19.0, we strictly enforce the error, going to option (a).  We retain the "old weird," but add a 
warning, which has some chance of breaking code.  (Most likely, the cynic in me supposes, by 
breaking "no warnings" tests, while the code that would've been effected is itself untested.)

(c) the "all things in moderation" option

We leave things exactly as they are in blead, post-50485807, but alter the emitted error to say 
"you can't put space where you put it."  This puts any likely breakage's starting point back in 
January (before the user-visible change freeze), and we move to option (a) in 5.19.0.  There are 
two down sides, here:  first, we're adding a new syntax error where there wasn't one without 
warning; secondly, we're introducing inconsistency.  The inconsistency doesn't bother me *as 
long as we fix it ASAP*.  This is like "we fixed a bunch of parts of a bug, and will continue to fix 
its other parts."  This kind of half-fix is something I am expressly okay with, as we're doing 
timeboxed releases.

That said, what's the win of (c) over (b)?  I'm not sure.  I don't think we really lose any momentum 
on the problem, nor do we return to some terrible state.


My original "all things equal, just fix the message" had in mind something like (c): Just change 
the text we emit so that we can release 5.18.0 and then fix things better.  Now it seems clear to 
me that we need a deprecation period for the bogus-space problem.  (Specifically, I'm thinking 
of code like that in the cpan grep, above.)

I think option (a) is right out for 5.18.0.

Karl also wrote:
> I suppose we could tweak the patch so that it gives an error in 
> precisely the same places as the misleading error would, and lets all 
> the other problematic constructs go by, unwarned on, and then change it 
> in 5.19 to warn. I haven't investigated how hard this would be.

Karl (or anybody) what is the difficulty in basically keeping the old behavior but issuing a 
warning on the problematic constructs *right away*, to be made fatal in 5.19.0-ish?  That is:  
can we enact option (b) in a timely way?


via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About