This proposal guarantees that Function.prototype.toString will represent callable built-in objects as NativeFunction productions, but imposes no requirements around presence or value of the resulting identifier. It would be very convenient for utilities like lodash isPlainObject if, when the method is called against objects appearing in the "Well-known Intrinsic Objects" table, the identifier could be specified to a) exist, and b) have a predictable value derived from the table (e.g., so Function.prototype.toString.call(Object) matches /function Object\b/). Similar treatment of built-in functions not appearing in the table (e.g., Array.prototype.push) would be nice but not required. Note, however, that modern implementations already do both.
A uniqueness constraint (per-realm or otherwise) could also be valuable, especially for dealing with bound functions, but is strictly less important than the above.
This proposal guarantees that Function.prototype.toString will represent callable built-in objects as NativeFunction productions, but imposes no requirements around presence or value of the resulting identifier. It would be very convenient for utilities like lodash
isPlainObjectif, when the method is called against objects appearing in the "Well-known Intrinsic Objects" table, the identifier could be specified to a) exist, and b) have a predictable value derived from the table (e.g., soFunction.prototype.toString.call(Object)matches/function Object\b/). Similar treatment of built-in functions not appearing in the table (e.g.,Array.prototype.push) would be nice but not required. Note, however, that modern implementations already do both.A uniqueness constraint (per-realm or otherwise) could also be valuable, especially for dealing with bound functions, but is strictly less important than the above.