Skip to content

Proposal for reducing Function.prototype.toString implementation flexibility

License

Notifications You must be signed in to change notification settings

tc39/proposal-stricter-function-tostring

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Stricter Function.prototype.toString

Status

  • Champion(s): Richard Gibson
  • Stage: 0

Motivation

The Function.prototype.toString revision proposal and its needs-consensus followup commit went a long way in constraining the output of Function.prototype.toString for built-in functions and other functions for which no source text representation is available, but left some implementation flexibility with respect to whitespace and the contents of that output taking the place of a function name. But the entire ecosystem benefits from uniformity across implementations, so such flexibility does not seem beneficial. This proposal is an attempt to impose further constraints and corresponding predictability. We do not have a preference regarding any particular representation, and are willing to negotiate with implementations as necessary.

Description

If adopted, this proposal will reduce implementation flexibility regarding the output of Function.prototype.toString that is described by the NativeFunction production (e.g., for built-in functions, bound functions, and proxied functions). The scope specifically includes whitespace, tokens in between function and (, and the syntactically invalid body, and may expand to include the parameter list as well.

Implementations

There are no known implementations.

About

Proposal for reducing Function.prototype.toString implementation flexibility

Resources

License

Code of conduct

Security policy

Stars

Watchers

Forks

Languages