allow engines to return alternative toString output when the source text is not stored

[michaelficarra]

This was the feedback from the committee today, so we will solve this before stage 4.

What mechanism should we use for this? Should it require all functions to have the same value? If not, does a function have to have a consistent value? Do we require web browsers to preserve the function source text?

/cc @domenic @phoddie

[domenic]

Please don't require web browsers to preserve the function source text. They run in low-memory environments too :).

It seems desirable for a function to have a consistent value, i.e. never have two observably-different values returned.

Whether that value is the same across all functions, I have fewer opinions on. Except, of course, that just using [native code] is easy on the compatibility concerns.

[michaelficarra]

It'd be easiest for me to add some HostHasSourceTextAvailable(fn) implementation-defined abstract operation which must return a consistent true/false value for any given function. @phoddie how do you feel about that?

[ljharb]

Maybe [unavailable code] to avoid breaking all the lodash and core-js code that checks for “is native”?

[jdalton]

Maybe [unavailable code] to avoid breaking all the lodash

Lodash dynamically generates its check based on a sample method so there is no hardcoded [native code] check, but it's the exception. At one time I had a list of libs using [native code], but haven't checked on it in a while.

[michaelficarra]

@syg What was the string you were thinking of returning for functions produced by binary AST?

[syg]

@michaelficarra I originally proposed "[sourceless code]" but I'm partial at this point to just everything censored/sourceless being reported as "[native code]".

[phoddie]

@michaelficarra HostHasSourceTextAvailable works for Moddable's use. Based on yesterday's presentation by @domenic it likely isn't granular enough for the web. Perhaps a solution for the current proposal is to retain "If the implementation cannot produce a source code string that meets these criteria then it must return a string for which eval will throw a SyntaxError exception," with the added requirement that the string returned be your proposal's [native code] source code. That would continue to work for XS while leaving the specification ready for @domenic's censor proposal to define the mechanisms to determine when source text is made unavailable.

[syg]

My takeaway from the proposal and surrounding discussion is that both hosts and content authors or distributors have legitimate reason to censor. I would prefer everybody to have the ability to censor each other, so long as nobody has the ability to uncensor.

[domenic]

It should be granular enough for the web for my host-controlled use case. (We might need some hand-waving that associates the function with the source file in which it was produced, but that's doable.)

I'd explore the additional pragma option for the library-controlled use case.