Look-behind proposal in trouble

[Nozomu Katoo]

Erik Corry wrote on Tue, 13 Oct 2015 at 11:18:48 +0200:
> Yes, that makes sense.
> 
> This could be fixed by removing {n} loops from positive lookbehinds.  Or by
> doing the .NET-style back-references immediately.

Personally, I am reluctant to remove any feature from the current
proposal intentionally for a future proposal that it is uncertain
whether it really comes or not. It might end up only making lookbehinds
of ECMAScript and ones of Perl 5 incompatible.

>> On 10/10/2015 03:48, Erik Corry wrote:
>>
>>>
>>> On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat wrote:
>>>
>>>     It's not a superset.  Captures would match differently.
>>>
>>>
>>> Can you elaborate?  How would they be different?
>>>
>>
>> If you have a capture inside a loop (controlled, say, by {n}), one of the
>> proposals would capture the first instance, while the other proposal would
>> capture the last instance.

I was missing that point. I just confirmed that

  perl -e "$a = 'abcdef'; $a =~ /(?<=.(.){2}.)./; print $1;"

returned 'c' whereas .NET returned 'b'. Implementation based on my
proposal would return the same result as Perl 5.


By the way, at one point in this thread, I moved some email addresses
from To to Cc when sending my reply. But somehow several of them had
disappeared from the Cc field in the delivered email while they all
remain in a copy in my sent-email folder. I apologize to those who
received disconnected emails in this thread.

Regards,
  Nozomu