Avoid implementation-dependent wording.
jdalton opened this issue · comments
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?
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.
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.).