He now convinced me and I'd support fixing it by making lookaheads be assertions, not atoms. They don't do what you'd expect if you apply any quantifier to them, which even fooled me.
Steven Levithan says that other languages disagree on this. Perl iterates the assertion (which ECMAScript doesn't do); PCRE makes it an error. Neither agrees with the current ECMAScript definition.
Waldemar
Lasse presented new evidence on the regular expression trac bug he filed: http://bugs.ecmascript.org/ticket/453
He now convinced me and I'd support fixing it by making lookaheads be assertions, not atoms. They don't do what you'd expect if you apply any quantifier to them, which even fooled me.
Steven Levithan says that other languages disagree on this. Perl iterates the assertion (which ECMAScript doesn't do); PCRE makes it an error. Neither agrees with the current ECMAScript definition.
Waldemar
Lasse presented new evidence on the regular expression trac bug he filed: bugs.ecmascript.org/ticket/453
He now convinced me and I'd support fixing it by making lookaheads be assertions, not atoms. They don't do what you'd expect if you apply any quantifier to them, which even fooled me.
Steven Levithan says that other languages disagree on this. Perl iterates the assertion (which ECMAScript doesn't do); PCRE makes it an error. Neither agrees with the current ECMAScript definition.
Lasse presented new evidence on the regular expression trac bug he filed: http://bugs.ecmascript.org/ticket/453 He now convinced me and I'd support fixing it by making lookaheads be assertions, not atoms. They don't do what you'd expect if you apply any quantifier to them, which even fooled me. Steven Levithan says that other languages disagree on this. Perl iterates the assertion (which ECMAScript doesn't do); PCRE makes it an error. Neither agrees with the current ECMAScript definition. Waldemar