Intl functions shouldn't be constructible

[goyakin]

According to the spec:

Built-in function objects that are not identified as constructors do not implement the [[Construct]] internal method unless otherwise specified in the description of a particular function

Since our Intl functions are script functions (implemented in Intl.js), they are constructible by default. For example,

new Intl.Collator.prototype.compare

causes the error:

TypeError: Collator.prototype.compare: 'this' is not a Collator object

instead of:

TypeError: Function is not a constructor

[dilijev]

@bterlson pointed me toward this discussion tc39/ecma402#57 as a potential concern, but tc39/ecma402#57 (comment) seems to suggest the Collator methods are not a problem.

[ljharb]

Could they be implemented as arrow functions, or do they need access to this?

[dilijev]

Unsure. I'll need to understand the spec and the linked discussion a bit better first.

[dilijev]

For myself for future reference: Intl documentation on MDN

[dilijev]

Not a functionality bug per se because we emit the correct kind of error, but the message is perhaps misleading. Adding Dev Experience and unassigning myself for now.

[jackhorton]

Was playing around with this a bit -- in chakra, anonymous function expressions bound to variables don't take the name of their variables (unlike at least in SpiderMonkey), so my initial belief on turning this into arrow functions is that the best error message we could get is "Function is not a constructor", rather than "getCanonicalLocales is not a constructor". @bterlson thoughts on if thats good enough?

[bterlson]

in chakra, anonymous function expressions bound to variables don't take the name of their variables (unlike at least in SpiderMonkey),

It seems like we do the right thing (let thing = () => {}; thing.name; => "thing"). If we're not doing this it's likely a bug... where are you seeing this behavior?

@bterlson thoughts on if thats good enough?

not good enough, but our errors messages generally need help. "Function is not a constructor" is in the family of "object is null or undefined" though, in that it isn't particularly helpful.

[jackhorton]

Seems like this should be fixable. Also interestingly, we definitely don't set the name property of normal function expressions assigned to variables, even though we do set the name of lambdas assigned to variables. I just confirmed this again locally but ran into it in Intl.js before.

[bterlson]

See also: #3407.