Front page | perl.perl5.porters |
Postings from February 2020
Karl Williamson <public@khwilliamson.com> wrote:
:I have further thoughts on this.
:
:On 2/11/20 5:01 AM, hv@crypt.org wrote:
[...]
:> On the other hand, I think the proposed change would break eg:
:> qr{ (?= foo (??{ bar() }) baz )+ }x
:> .. which I think is an argument against rushing anything out for the more
:> general case - IIRC we already have bugs backtracking over lookaheads
:> with backreferences, probably due to similar thinking.
:
:You are right. I neglected to mention that the change would not affect
:assertions that have things like (??...) in them. In regcomp.c, one of
:the flags that does seem to work is POSTPONED, which indicates that one
:of these has been seen within the current construct. That flag signals
:that these optimizations should not be applied.
:
:But I forgot to consider what happens when a \K has a POSTPONED
:construct in it. So your point brought that to my attention.
:>
:> For the specific case of \K however I see no obvious barrier to optimizing
:> /\K{m, n}/ to one of noop, \K? or \K.
:
:What about POSTPONED constructs? I'm unclear about this.
I thought we were talking about /foo (?:\K+)/, not /(?:foo \K)+/?
I had assumed that \K only had to (effectively) set a pointer to what
we're now pretending the match point is, and the second iteration
of a \K{1,2} would just need to set the pointer to that same thing.
If that's not the case, it would probably help to have a concrete
example - I've never actually used \K, I had to look up the definition
when this thread first started. Unfortunately I don't see a reference
to the motivating ticket in the commit or what I still have handy of
this thread, or I'd go look there.
Hugo
Thread Previous
|
Thread Next