search

tc39 / Function-prototype-toString-revision

:fishing_pole_and_fish: ECMA-262 proposal to update Function.prototype.toString
https://tc39.github.io/Function-prototype-toString-revision
26 stars 10 forks source link

Avoid implementation-dependent wording. #16

Closed jdalton closed 8 years ago

jdalton commented 8 years ago

In the Function#toString definition:

If func is a Bound Function exotic object or a built-in Function object, then return an implementation-dependent String source code representation of func. The representation must have the syntax of a NativeFunction.

Since the goal is to unify Function#toString implementations is there a need for "implementation-dependent" (which adds wiggly room?) when the representation "must conform" to NativeFunction is present?

michaelficarra commented 8 years ago

Yes, the particular whitespace, comments, or identifier escape sequences that must be used is not defined by this proposal. It simply must match that grammar production.

jdalton commented 8 years ago

It's seems kind of odd to leave unspecified behavior in this revision. Shouldn't we spec-ify and close-gaps-in the de facto behavior around this? For example, specifying the string representation of a user defined function must reflect its source text verbatim (tabs, spaces, new lines, comments, etc.).