You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.
I think we should just make it an invariant that all well-known intrinsics that are functions be given names.
Currently well-known intrinsics are extended when external specifications like to have an entry for a built-in function (tc39/ecma262#1105). That means when an external spec likes to have a reference to a currently anonymous built-in, the built-in needs to be named before it can be added as a well-known intrinsic. And I'm not sure I like to have this kind of dependency in the spec. It feels a bit obscure. Also when a well-known intrinsic entry is no longer needed, would it be possible to change the function back to be anonymous or do we need to keep the name for compatibility reasons?
This may all change with tc39/ecma262#1049 which ditches the concept of anonymous functions, but until we have a decision for that issue, I'd say @claudepache 's proposal at #14 (comment) seems to be the better choice here.
The text was updated successfully, but these errors were encountered:
Follow-up from #14
#14 (comment)
Currently well-known intrinsics are extended when external specifications like to have an entry for a built-in function (tc39/ecma262#1105). That means when an external spec likes to have a reference to a currently anonymous built-in, the built-in needs to be named before it can be added as a well-known intrinsic. And I'm not sure I like to have this kind of dependency in the spec. It feels a bit obscure. Also when a well-known intrinsic entry is no longer needed, would it be possible to change the function back to be anonymous or do we need to keep the name for compatibility reasons?
This may all change with tc39/ecma262#1049 which ditches the concept of anonymous functions, but until we have a decision for that issue, I'd say @claudepache 's proposal at #14 (comment) seems to be the better choice here.
The text was updated successfully, but these errors were encountered: