I ave to recant on this after having doing some research (and actually making it work). The original reason about ThisMode may still be true but I'm less sure. It was basically about being unable to identify the correct global `this` in strict mode since its not automatically provided for you, and multiple global is now a common thing in es6, but I don't think this ended up gmpering anything in actual usage.<div>
<br></div><div>The other reason was because of ThrowTypeError, which requires a.) adding multiple accessor own properties to every function object, and b.) modified GetOwnProperty semantics. Upon inspection, I couldn't actually find anything in the spec that prohibits builtin functions from having those ThrowTypeError accessors like I had originally supposed there was. In my implementation I cheat and use magic to remove them even though the functions are compiled as strict (they're in implicit module bodies) but I now realize that's not necessary, at least to be spec compliant.<span></span></div>
<div><br>On Thursday, December 27, 2012, David Bruant  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 27/12/2012 02:52, Brandon Benvie a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As an aside, ES itself can't self-host its own builtins in strict mode because of the (two of the very few) semantic differences that exist between strict mode and non-strict mode: non-strict thrower properties (which I've come to consider an annoying blight that punishes developers in order to influence implementers) and strict this-mode differences. Every semantic difference you mandate furthers this gap.<br>

</blockquote>
I fail to understand why built-ins can't be implemented in strict mode. Can you provide a concrete example of something that can't?<br>
<br>
Thanks,<br>
<br>
David<br>
</blockquote></div>