No one has yet submitted a well-defined proposal for lookbehinds on the table.  Lookbehinds are difficult to translate into the language used by the spec and get quite fuzzy when the order of evaluation of parts of the regexp matters, which is what happens if capturing parentheses are involved.  Where do you start looking for the lookbehind?  Shortest first, longest first, or reverse string match?  Greedy or not?  Backtrack into capturing results?

     Waldemar


On 09/28/2013 01:54 PM, Sebastian Zartner wrote:
> I wonder if the discussion about lookbehinds[1] and Marc Harter's proposal for them[2] in the past led to anything.
> I'd really like to see these implemented in ECMAScript specification and it seems I am not the only one.[3][4][5] This even caused people to try to mimic them.[6]
> So I wanted to pick up the discussion again and ask, what info was missing that they didn't get specified?
>
> Sebastian
>
> [1] https://mail.mozilla.org/pipermail/es-discuss/2010-November/012164.html
> [2] https://docs.google.com/document/pub?id=1EUHvr1SC72g6OPo5fJjelVESpd4nI0D5NQpF3oUO5UM
> [3] http://stackoverflow.com/questions/12273112/will-js-regex-ever-get-lookbehind
> [4] http://stackoverflow.com/questions/13993793/error-using-both-lookahead-and-look-behind-regex
> [5] http://regexadvice.com/forums/thread/85210.aspx
> [6] http://blog.stevenlevithan.com/archives/mimic-lookbehind-javascript
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

No one has yet submitted a well-defined proposal for lookbehinds on the table.  Lookbehinds are difficult to translate into the language used by the spec and get quite fuzzy when the order of evaluation of parts of the regexp matters, which is what happens if capturing parentheses are involved.  Where do you start looking for the lookbehind?  Shortest first, longest first, or reverse string match?  Greedy or not?  Backtrack into capturing results?