<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Oct 14, 2010, at 1:39 PM, Jeff Walden wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 10/14/2010 08:29 AM, Brendan Eich wrote:<br><blockquote type="cite">Thus there is already one bit of opt-in versioning state in ES5, which must be carried from direct eval's caller to callee.<br></blockquote><br>SpiderMonkey currently does this,</div></blockquote><div><br></div>I wasn't describing any implementation, I was citing ES5 10.1.1, second bullet:</div><div><font class="Apple-style-span" face="Arial"><font class="Apple-style-span" face="Helvetica"><br></font></font></div><div><span class="Apple-style-span" style="font-family: Arial; font-size: 10px; ">* Eval code is strict eval code if it begins with a Directive Prologue that contains a Use Strict Directive or if the call to eval is a direct call (see 15.1.2.1.1) to the eval function that is contained in strict mode code.&nbsp;</span></div><div><div><br></div><div><br></div><blockquote type="cite"><div> but fairly shortly (I have patches) it will not. &nbsp;The eval *function*'s implementation will always perform indirect eval, and only the eval opcode will perform direct eval. &nbsp;(We could statically distinguish strict+direct from non-strict+direct, too, with a separate opcode, but since it's trivial to query the currently executing script's strictness, runtime detection seems better than burning an opcode.)<br><br>That's only SpiderMonkey, of course, but as far as I can tell the concepts are applicable to any ECMAScript implementation.</div></blockquote><br></div><div>This is an implementation detail, independent of ES5 10.1.1 and unobservable unless there's a bug.</div><div><br></div><div>/be</div><br></body></html>