<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 8 déc. 2019 à 20:49, Jack Works <<a href="mailto:zjwpeter@gmail.com" class="">zjwpeter@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">I thought the "caller" has been removed from the spec, so there isn't much to do with the "caller" since it is not standard. It's implementation's own extension.<div dir="auto" class="">But maybe we can also extend The forbidden extensions section.</div></div></div></blockquote><div><br class=""></div><div>The `caller` property of functions (not to be confused with the `caller` property of the `arguments` object, which is indeed dead) has never been in the spec, except some restrictions in the [Forbidden Extensions] section introduced at the same time as strict-mode functions. And the problem is, precisely, that it is underspecified.</div><div><br class=""></div><div>Now, it is indeed almost trivial to resolve spec-wise *the particular* issue you noted, by amending the [Forbidden Extensions] section: Just find the bullet that begins with “If an implementation extends any function object with an own property named "caller"...”, and replace therein all occurrences of “strict function” with “strict function or built-in function” (or maybe with “anything but a non-strict function”). That, however, is not the most implementation-friendly way, because that leaves up to them to guess what to do instead (return null, throw an error, etc.), that will not break the web for their users. </div><div><br class=""></div><div>Moreover, the `caller` property has most probably some other gotchas; one of them I recall to have noted some time ago, is that, in at least one implementation, it is publicised as a non-writable, non-configurable own data property, but it may change its value.</div><div><br class=""></div><div>I think that it is better, at this point, to specify Function#caller and Function#arguments, as proposed in [gh-issue 562].</div><div><br class=""></div><div>[Forbidden Extensions]: <a href="https://tc39.es/ecma262/#sec-forbidden-extensions" class="">https://tc39.es/ecma262/#sec-forbidden-extensions</a></div><div>[gh-issue 562]: <a href="https://github.com/tc39/ecma262/issues/562" class="">https://github.com/tc39/ecma262/issues/562</a></div><div><br class=""></div><div>—Claude</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 9, 2019, 1:12 AM Claude Pache <<a href="mailto:claude.pache@gmail.com" rel="noreferrer noreferrer" target="_blank" class="">claude.pache@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">Le 8 déc. 2019 à 14:43, Jack Works <<a href="mailto:zjwpeter@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank" class="">zjwpeter@gmail.com</a>> a écrit :<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><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" rel="noreferrer noreferrer noreferrer" target="_blank" class="">https://github.com/Jack-Works/proposal-strict-built-in-functions</a></div><div class="gmail_default" style="font-family:simhei,sans-serif"><br class=""></div></div></div></blockquote><div class=""><br class=""></div>Hi,<div class=""><br class=""></div><div class="">See <a href="https://github.com/tc39/ecma262/issues/562#issuecomment-218531285" rel="noreferrer noreferrer noreferrer" target="_blank" class="">https://github.com/tc39/ecma262/issues/562#issuecomment-218531285</a> for another  testcase. </div><div class=""><br class=""></div><div class="">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" rel="noreferrer noreferrer noreferrer" target="_blank" class="">https://tc39.es/ecma262/#sec-forbidden-extensions</a>, but they are insufficient.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">—Claude</div></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>