<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">Le 8 déc. 2019 à 14:43, Jack Works <zjwpeter@gmail.com> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:simhei,sans-serif">In the current spec, strictness of the built-in functions are implementation-dependent behaviors. This proposal is going to fix this problem.</div><div class="gmail_default" style="font-family:simhei,sans-serif"><a href="https://github.com/Jack-Works/proposal-strict-built-in-functions" style="font-family:Arial,Helvetica,sans-serif">https://github.com/Jack-Works/proposal-strict-built-in-functions</a></div><div class="gmail_default" style="font-family:simhei,sans-serif"><br></div></div></div></blockquote><div><br></div>Hi,<div><br></div><div>See <a href="https://github.com/tc39/ecma262/issues/562#issuecomment-218531285">https://github.com/tc39/ecma262/issues/562#issuecomment-218531285</a> for another  testcase. </div><div><br></div><div>The real problem is that the semantics of `f.caller` is left to implementations. There are in fact some restrictions in the spec, see <a href="https://tc39.es/ecma262/#sec-forbidden-extensions">https://tc39.es/ecma262/#sec-forbidden-extensions</a>, but they are insufficient.</div><div><br></div><div>Note that it doesn’t really make sense to mandate that builtin functions be “strict”: The notion of strictness is defined only for so-called ECMAScript functions, which are functions whose implementation is written in ECMAScript code. That excludes builtin functions (unless the implementation choose to  implement them in ECMAScript), but also bound functions, proxies, and probably some other cases. </div><div><br></div><div>—Claude</div></div></body></html>