Re^2: curious regex result for perl 5.8.8

If there is no match the content of the capture variables is bogus

That's not strictly accurate. The capture variables reflect the last successful match, where that match is dynamically scoped. The 5.8.x behaviour was a bug, fixed in 5.10.0 by commit c74340f9cdee.

Dave.

Comment on Re^2: curious regex result for perl 5.8.8

Replies are listed 'Best First'.
Re^3: curious regex result for perl 5.8.8 by GrandFather (Saint) on Jun 22, 2016 at 02:02 UTC
"That's not strictly accurate." Oh yes it is, probably! If there was no match then it's easy to argue that there should be no capture. If there was no capture the contents of the capture variables should be undef. The current "last capture" behavior then can easily and accurately be described as bogus. :-) I can understand that there are compelling (probably historical compatibility) reasons for the current behavior. In a big picture sense that doesn't make the behavior less bogus. Besides, bogus is a fun word so I like to use it - what's bogus with that? Premature optimization is the root of all job security	[reply]
Re^4: curious regex result for perl 5.8.8 by Anonymous Monk on Jun 22, 2016 at 02:15 UTC
yeah , traditions are totally bogus, on ward python soldiers ...	[reply]
Re^5: curious regex result for perl 5.8.8 by GrandFather (Saint) on Jun 22, 2016 at 04:13 UTC
You misunderstand. Backward compatibility is important. The behavior in the context of prior art is correct and consistent. The behavior in the context of naive expected outcome following a failed match is bogus. The Apple/Python/PHP/Perl 6/... attitude of "onward and bugger legacy code" is anathema (although I understand where it comes from). This is not that! Premature optimization is the root of all job security	[reply]