What do you mean by “strict function”

[claudepache]

By definition, a strict function, resp. a non-strict function, is an ECMAScript function whose code is in strict mode code, resp. non-strict mode code. Such a definition makes sense only for ECMAScript functions.

But you seem to give some other meaning for “strict” that would apply to non-ECMAScript functions (as builtin functions are, in practice, most often non-ECMAScript). I tried to think of some reasonable definition, but I couldn’t find one.

So, what do you mean exactly by “strict function”?

[ljharb]

Given that it’s observable from outside wrt arguments/caller, it makes sense to me for any function of any origin.

[claudepache]

@ljharb If a function is not censored for .caller and .arguments, then it is non-strict. But the implication goes only in one direction, so it cannot be used as a criterion for distinguishing between strict and non-strict. For instance, in JSC (and possibly other engines), it is impossible to distinguish between a non-strict generator function and a strict generator function using only .arguments and .caller.

I have guessed that there could have been some relation with the behaviour of .caller and .arguments, but, as I said, it didn’t suggested to me any reasonable definition of “strict”.

[Jack-Works]

I had a misunderstood about strict. I thought all functions are strict or nonstrict. I thought it is binary.

Now I know the "strict" only used in ECMAScript functions. With this nonbinary meaning, any words of "strict function" or "non-string function" will become a dangerous trap.

As you can see, we fall into this trap (.caller must not be a strict function, the editor might think that equals to "loose" functions), I think it's better to specify the "strictness" of non-ECMAScript functions so the "strict/nonstrict" can be a binary relation and never fall in to bug like this case.

e.g. All built-in function will be treated as strict (in the comparison like "must be strict" or "must not be strict") The bound function (returned by f.bind()) is strict when f is strict, vice verse.

[ljharb]

I also see it more as, “is this function sloppy? If i can’t determine that it is, including by looking at the code, then it’s strict”

[claudepache]

Ok, I’m still unconvinced, but let me go to the point. Why do we want a distinction between “strict” and “non-strict” non-ECMAScript function? Is it just for restrictions around .caller and .arguments, or are there other uses?

[ljharb]

Why do we care if a function is non-ECMAScript or not? ECMAScript functions may or may not have source available, so I'm not sure why it matters.

[claudepache]

@ljharb What I care about, is that the notion of “strict function” be sound with a clear purpose.

[Jack-Works]

There is not many use case of strict or non-strict and it might not increase in the future. So another way is to review all the current use cases of strict and non-strict to see if there is any that uses the term that not reflecting the design purpose (and might cause a bug).

[hax]

ECMAScript functions may or may not have source available

@ljharb I am not sure what that mean. Isn't ECMAScript functions always have ECMAScript code by definition?

[ljharb]

@hax function () {}.bind() is an ecmascript function that does not have source text available.

[hax]

@ljharb As I understand bound functions are not ECMAScript functions.

[ljharb]

ok, fair enough - then both of the implementation hiding proposal, or the Function.prototype.toString source hook that's already in the spec, can allow ECMAScript functions without available source text ¯\_(ツ)_/¯

[hax]

@ljharb They only hide source for the 3rd party libraries in runtime, seems no relation to engines?

[ljharb]

Engines have source text available for their c++ functions, it’s just not JS code.

[claudepache]

The issue of availability of source code is off-topic; it is orthogonal both to the issue of strictness and to the issue of .caller and .arguments.

[Jack-Works]

@erights I have mentioned my idea here https://github.com/Jack-Works/proposal-strict-built-in-functions/issues/3#issuecomment-577789819

I think it's better to specify every kind of non-ES functions case by case so .bind can specify its result as a non-strict function.

So on this purpose maybe it no longer gets covered by Claude's proposal. Maybe we should re-add it as a separate work?

[erights]

First, we made stage 1. Congrats to us!

What is the current behavior of bound functions? Can someone do these same tests across browsers? Thanks.

[ljharb]

@erights can you give me some code? i can run it in eshost.

[erights]

@claudepache do you have the code you tested with?

To be clear, what made it to stage 1 is the combination of the two proposals.

[claudepache]

Le 6 févr. 2020 à 03:33, Mark S. Miller notifications@github.com a écrit :

 First, we made stage 1. Congrats to us!

What is the current behavior of bound functions? Can someone do these same tests across browsers? Thanks.

See https://github.com/claudepache/es-legacy-function-reflection/issues/6#issuecomment-575162851

—Claude

[ljharb]

try {
        print((function(){}).caller);
} catch (e) { print(e); }

try {
        print((function(){}).bind().caller);
} catch (e) { print(e); }

yields:

#### ch
null
TypeError: 'arguments', 'callee' and 'caller' are restricted function properties and cannot be accessed in this context

#### Chakra
null
TypeError: 'arguments', 'callee' and 'caller' are restricted function properties and cannot be accessed in this context

#### JavaScriptCore
null
TypeError: 'arguments', 'callee', and 'caller' cannot be accessed in this context.

#### jsc
null
TypeError: 'arguments', 'callee', and 'caller' cannot be accessed in this context.

#### sm
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them

#### SpiderMonkey
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them

#### v8
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them

#### V8
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them

#### V8 --harmony
null
TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them

#### xs
undefined
TypeError: ?: strict mode

[claudepache]

Le 6 févr. 2020 à 03:57, Mark S. Miller notifications@github.com a écrit :

 @claudepache do you have the code you tested with?

Here are some tests:

https://github.com/claudepache/es-legacy-function-reflection/blob/master/simple-tests.js

For bound functions and proxies, you may need to carefully follow their semantics in order to correctly interpret the results.

[claudepache]

For bound functions and proxies, you may need to carefully follow their semantics in order to correctly interpret the results.

More precisely:

• When you do proxy.caller, one of the following things will happen: either the “get” handler will be triggered, or the property lookup will be made on [[ProxyTarget]] but with the same “receiver” as the original lookup. In the latter case, the result will depend on whether .caller is implemented as a magic data property (the receiver will be ignored) or as an accessor (the receiver will be taken into account).
• Neither proxies, nor bound functions will be considered as “caller” of anything; instead either the function they wrap or the corresponding handler will play that role. (That follows from their [[Call]]/[[Construct]] semantics.) As a consequence, they won’t ever appear as a (potential) result from a .caller lookup.