Motivation is not clear

[hax]

The motivation part use a complex example which involves Proxy/Reflect, I feel it's not easy to understand.

Consider all current implementations already make all builtin functions behave like strict (any exception?), the motivation of this proposal could be just a simplification of spec/implementation.

And maybe it could be need-consensus PR which do not need several stages.

[Jack-Works]

Consider all current implementations already make all builtin functions strict (any exception?)

If we assume Edge is implementing getOwnProperty... in native code, there is no mention in the spec to restrict that function must be strict. If Edge implemented it as a non-strict function, return the following result is not violating 9.3 Built-in function Objects nor 16.2 Forbidden Extensions.

The first motivation is to prevent an implementation mark a native built-in function as a non-strict function. The second motivation is to keep consistency between implementations about this topic.

it could be need-consensus PR

What do you think? @erights

Also, I think maybe we should check for the web compatibility first.

[hax]

Accessing Reflect.getOwnPropertyDescriptor.caller throw error in all current engines (includes latest ChakraCore), so as I understand it already behave like strict function no matter it was native or es code.

Note, If a function is non-strict, f.caller should return null in most cases (for example, builtin functions in Node 6-).

So the issue in the screenshot is a separate bug of Chakra (violate Proxy invariant of never return strict function).

[claudepache]

@hax The precise issue in ChakraCore is that Reflect.getOwnPropertyDescriptor (a non-ECMAScript function, for which there is no notion of “strictness”) may be returned by randomFunc.caller (where randomFunc is a non-strict function). The current language of the spec is not sufficient for forbidding that. This has nothing to do with Proxy invariants.

[hax]

@claudepache

I should use "behave like strict function" in my previous comments :-)

Anyway, current proposal:

- Built-in functions that are ECMAScript function objects must be strict functions. + Built-in function objects must be strict functions.

is also problematic if non-ES functions do not have notion of strictness. (also the sentence of "Therefore the "strictness" of the built-in function is unstable between implementations" in README)

[claudepache]

Anyway, current proposal:

~- Built-in functions that are ECMAScript function objects must be strict functions.~

• Built-in function objects must be strict functions.

is also problematic if non-ES functions do not have notion of strictness.

Manifestly, the intent is to redefine the notion of “strict function”, so that it encompasses what is currently called “strict functions” as well as non-ECMAScript functions.

(also the sentence of "Therefore the "strictness" of the built-in function is unstable between implementations" in README)

(Even, I don’t understand what this sentence is supposed to mean.)

[Jack-Works]

I'm mean by, currently, an implementation can implement a built-in function as strict or non-strict if it is written by native code.

Although it is not a serious problem (it is hard to detect if a function is strict in the current language), another motivation is to force all implementation to implement it as strict to reduce the difference between platforms.

[hax]

A simple solution may be change the words of this paragraph:

If an implementation extends any function object with an own property named "caller" the value of that property, as observed using [[Get]] or [[GetOwnProperty]], if a function object, it must not be a non-strict function object. If it is an accessor property, the function that is the value of the property's [[Get]] attribute, if return a function object when called, the function object must never returnbe a non-strict function when called.

[claudepache]

I agree with @hax: it is more expeditive to review and fix the very few places where “strict function” is used in a context where it makes sense to speak also about non-ECMAScript function (AFAICS, the two first items in the the Forbidden Extensions section and the last item in Annex C, all of them pertaining to restrictions around .caller and .arguments) than to try to give some sense to the notion of strict non-ECMAScript functions.