Closed claudepache closed 4 years ago
It's already possible to detect strictness of a function object f
by simply check whether f.caller
throw. (Though theoretically it can only detect non-strict function declaration/expression)
When I say that the implementation technique of a function should not be detectable, it is specifically so that both implementations and users may refactor the code they control without provoking too much breakage when entering in contact with unrelated or poorly written third-party code.
Of course, this is not a reasonable hard constraint for Function#caller and Function#arguments, and even for Function#toString(). But we should strive to limit the set of functionalities for which the problem will occur.
The IsLeakableFunction operation introduced in this proposal is intended to be used specifically in the scope of this proposal, and we shouldn’t encourage its use as a generic tool for discriminating between good and bad functions.
In fact, ECMA-262 has already a name for “bad” function objects: it is the so-called non-strict functions. The specific abstract operation defined in the scope of this proposal uses more severe criteria, because it has additional goals: deprecate the functionality, follow de-facto semantics, etc.
The IsLeakableFunction operation introduced in this proposal is intended to be used specifically in the scope of this proposal, and we shouldn’t encourage its use as a generic tool for discriminating between good and bad functions.
Indeed, it should normally not be detectable whether a function is implemented in strict ES, sloppy ES, or Fortran.
Precedent: “undefined-like object” was changed to “has an [[IsHTMLDDA]] internal slot”.