[Webkit-unassigned] [Bug 23418] Regular expression literals are not being "shared" inside a function

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=23418


ggaren at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




------- Comment #3 from ggaren at apple.com  2009-01-19 11:45 PDT -------
The latest proposed version of the ECMA specification gives the nod to
WebKit's/IE's behavior, calling the previous specification a bug:

[http://www.ecmascript.org/es4/spec/incompatibilities.pdf]

1.1. Evaluation of a RegExp Literal Results in a new RegExp 
Description 
In ES3 a regular expression literal like /a*b/mg denotes a single unique RegExp
object that is created the 
first time the literal is encountered during evaluation.  In ES4 a new RegExp
object is created every time 
the literal is encountered during evaluation. 

Rationale 
This is a bug fix.  The create-once behavior in ES3 is contrary to programmer
expectation.3  If a RegExp 
object created by a literal is used for matching, its lastIndex property will
be left in a non-initial state 
after a match; programmers who expect lastIndex to be reset to zero the next
time the literal is evaluated 
(because they expect a new RegExp object to be created) will be surprised.  The
bug bites even advanced 
programmers. 

Impact 
The changed behavior is observable because RegExp objects are mutable and the
literal no longer 
corresponds to a single, unique object.  In practice the change is most
observable in that the lastIndex 
property of the (new) RegExp object is in an initial state every time the
literal is evaluated, as desired. 

Implementation precedent 
Internet Explorer 6 and Safari 3 create a new RegExp object every time the
literal is encountered during 
evaluation. 


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.