Requiring production of source code infeasible for some environments

[phoddie]

I’m following up on the discussion https://esdiscuss.org/notes/2017-07-25#11iia-functionprototypetostring-looking-for-stage-4 . This feedback is from Patrick Soquet and me, both of Moddable Tech.

We would like to confirm that we agree with the majority of the proposal. It is indeed useful to clarify the result of Function.prototype.toString.

At the TC39 meeting, we shared why XS, our JavaScript virtual machine, cannot produce a source code string. From our talks with other members, it appears other implementations cannot, or do not want to, produce a source code string in some circumstances, for example in a realm with strong security requirements or to reduce memory use.

The current specifications allow that behavior, albeit in a way that is indeed theoretically “forward-incompatible”. Thank you for your explanations.

What we propose is an implementation-defined abstract operation that allows host environments to block the production of a source code string.

Something like HostEnsureCanDecompileFunctions( realm ), for example, would be symmetrical to the existing HostEnsureCanCompileStrings( callerRealm, calleeRealm ).

Any abrupt completions of HostEnsureCanDecompileFunctions would be propagated to its callers.The default implementation of HostEnsureCanDecompileFunctions is to unconditionally return an empty normal completion.

A realm that does not return source code from Function.prototype.toString would break the web. Consequently, it may be appropriate to require it be supported in Annex B.

[michaelficarra]

@phoddie Something not captured in the notes was my assertion that these constrained implementations likely already do not fully implement ECMA-262. As an example, I gave the Unicode case mapping tables required by String.prototype.toLowerCase. For these partial implementations alone, it doesn't seem important to introduce the abstract operation; they can continue violating chosen portions of the standard.

I've not been made aware of the other cases you mention:

it appears other implementations cannot, or do not want to, produce a source code string in some circumstances, for example in a realm with strong security requirements or to reduce memory use.

Can you give me more information about these requirements?

On the topic of moving Function.prototype.toString to Annex B: I would be more than happy to do so, but some members may object. @bterlson @allenwb Who should I involve in that discussion? Is this something I should get committee consensus on before including in this proposal?

[bterlson]

This is fairly easy to move into annex b. It would require consensus. I'm not sure it's the right choice, though. If you can return a string, the string should conform to this proposal. Whether you can throw rather than return a string could be an orthogonal matter handled via another proposal.

[ajklein]

This may be a reference to a hallway conversation involving me. On memory constrained devices, there has been some discussion of whether Chrome could disallow (or return an empty string from) toString to avoid having to hold onto source code longer than necessary, possibly with the opt-in of the page (similar to how we do CSP). The strawperson suggested by @phoddie could be useful for such a strategy.

I agree with @bterlson, though, that I think this feature request is orthogonal to Michael's proposal. I'd prefer to see that proposal remain as-is, and for @phoddie to move this issue either to the ecma262 tracker or to a new proposal.

[phoddie]

@michaelficarra I’m uncomfortable with the suggestion that we should not consider the impact of proposals on constrained devices for the sole reason that they have historically being non-conforming in some ways. Being unwilling to consider the needs of such devices all but ensures they will always be non-conforming. Our work at Moddable has the goal to be compatible with the standard.

You reasonably ask for “more information about these requirements” referring to comments about memory and security impact. Please understand that these were not intended as or presented as requirements. They are background. Being new to the committee, I apologize for not yet being able to attach names to every faces from conversations during the meetings. I will see if can reconnect those next week in Boston and get back to you then.

The comment regarding Annex B was unintentionally ambiguous. Apologies. We are not proposing to move all of Function.prototype.toString to Annex B. It should remain where it is. If an implementation returns source code to a function, on the web or elsewhere, it should conform to Michael’s proposed text. The comment regarding Annex B was should have said simply “HostEnsureCanDecompileFunctions is always supported in web browsers.”

To @bterlson’s comment as to whether to throw or return a string indicating source code is unavailable (for example, a parallel to NativeFunction in Michael’s proposal), either would be acceptable.

[bterlson]

return a string indicating source code is unavailable

FWIW, I like this alternative best, where it's still a function with a body like [ source text unavailable ].

[phoddie]

@ajklein - Yes, thank you for filling in the details.

I think we're open to moving this issue to ecma262 tracker or to a new proposal, if that's the usual process. Maybe a side conversation next week would be a quick way to decide the right path ahead.