We should consider adding a RealmOption for this stuff. Then we could easily turn this off for content code and reduce our attack surface, without worrying about browser chrome/devtools and shell consumers. Just need to make sure the Xray code works correctly.

I will look into Jan's idea. However conditionally defining functions is always a bit complicated, but I think we can solve this by introducing a JSFunctionSpec for toSource, or maybe just match the name?

I know it is too late to enter discussion, but I feel obligated to plead in favor keeping toSource, at least in devtools (Web Console) context (if possible).

While Rich Outputs ("Xrays"(?)) in the Console are excellent and keep improving, I've found invoking good old trusty toSource very convenient to this days:

• On strings it unambiguously reveals control and "non-ASCII" code points (i.e. something that could be cumbersomely emulatable with .split and .map):
  • » '🛩️\r\n🛩'.toSource()
  • « "(new String(\"\\uD83D\\uDEE9\\uFE0F\\r\\n\\uD83D\\uDEE9\"))"
• On objects it conveniently reveals all method sources (i.e. something that could be hardly emulated in concise oneliner):
  • » ({a:function(){/*foo*/},b:function(){/*bar*/}}).toSource()
  • « "({a:(function(){/*foo*/}), b:(function(){/*bar*/})})"

Even though this plead is most probably futile, I owe this ancient little gem too much time it saved me and too much pride for neat non-standard benefit in favourite browser it gave me to remain silent. Then be this comment a sincere eulogy.

(I don't remember I've ever used uneval, but I can imagine I could switch to it if it remained as the only option after toSource removal.)

After removing toSource completely, the following tests (D56935 and D56940) that use toSource only conditionally should be updated.