The [[Match]] property was accessed in step 9 in ES5.1 (cf. 15.10.6.2 RegExp.prototype.exec), but has been changed to step 2 (cf. [[RegExpMatcher]] in RegExpExec abstract operation). This change is potentially user [visible] due to the non-standard RegExp.prototype.compile function.
Example:
var r = /a/;
r.lastIndex = {valueOf: function(){ print("compile"); r.compile("b","g") }};
r.exec("b")
V8 and Opera(12.15 - not V8 based) both return ["b"], whereas SpiderMonkey
returns null. (JSC and IE10 don't even execute the valueOf function.)
Per the current ES6 draft, the expected result is null.
The change in the ES6 spec. is to capture the internal pattern matcher state before accessing lastIndex (which could have side-effects of changing the pattern) rather than after that access.
Because of the disagreement among existing implementation I think we can decide this based upon first principles rather than being constrained by backwards compatibility.
While the current V8/Opera 12.15 behavior is consistent with the ES<=5.1 spec, I suggest that the most likely intent of code like foo.exe("string to match") is to use foo's pattern as of the time of the call rather than some new pattern that is introduced as a side-effect of an internal access. In that case, the revised ES6 spec. seems fine and the current SpiderMonkey behavior is the most reasonable. The JSC/IE10 behavior is buggy in either case.
The following is from ES6 bug 1575 submitted by André Bargull
The
[[Match]]property was accessed in step 9 in ES5.1 (cf. 15.10.6.2RegExp.prototype.exec), but has been changed to step 2 (cf.[[RegExpMatcher]]inRegExpExecabstract operation). This change is potentially user [visible] due to the non-standardRegExp.prototype.compilefunction.Example:
var r = /a/; r.lastIndex = {valueOf: function(){ print("compile"); r.compile("b","g") }}; r.exec("b")V8 and Opera(12.15 - not V8 based) both return
["b"], whereas SpiderMonkey returnsnull. (JSC and IE10 don't even execute thevalueOffunction.)Per the current ES6 draft, the expected result is
null.The change in the ES6 spec. is to capture the internal pattern matcher state before accessing
lastIndex(which could have side-effects of changing the pattern) rather than after that access.Because of the disagreement among existing implementation I think we can decide this based upon first principles rather than being constrained by backwards compatibility.
While the current V8/Opera 12.15 behavior is consistent with the ES<=5.1 spec, I suggest that the most likely intent of code like
foo.exe("string to match")is to use foo's pattern as of the time of the call rather than some new pattern that is introduced as a side-effect of an internal access. In that case, the revised ES6 spec. seems fine and the current SpiderMonkey behavior is the most reasonable. The JSC/IE10 behavior is buggy in either case.Any disagreement?
The following is from ES6 bug 1575 submitted by André Bargull ---------------------------------- The [[Match]] property was accessed in step 9 in ES5.1 (cf. 15.10.6.2 RegExp.prototype.exec), but has been changed to step 2 (cf. [[RegExpMatcher]] in RegExpExec abstract operation). This change is potentially user [visible] due to the non-standard RegExp.prototype.compile function. Example: --- var r = /a/; r.lastIndex = {valueOf: function(){ print("compile"); r.compile("b","g") }}; r.exec("b") --- V8 and Opera(12.15 - not V8 based) both return `["b"]`, whereas SpiderMonkey returns `null`. (JSC and IE10 don't even execute the valueOf function.) Per the current ES6 draft, the expected result is `null`. --------------------------------- The change in the ES6 spec. is to capture the internal pattern matcher state before accessing lastIndex (which could have side-effects of changing the pattern) rather than after that access. Because of the disagreement among existing implementation I think we can decide this based upon first principles rather than being constrained by backwards compatibility. While the current V8/Opera 12.15 behavior is consistent with the ES<=5.1 spec, I suggest that the most likely intent of code like foo.exe("string to match") is to use foo's pattern as of the time of the call rather than some new pattern that is introduced as a side-effect of an internal access. In that case, the revised ES6 spec. seems fine and the current SpiderMonkey behavior is the most reasonable. The JSC/IE10 behavior is buggy in either case. Any disagreement? Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130704/fc700861/attachment.html>