Why describe censored code as "[native code]"?

[garvank]

I work on a library that is often interfered with by things like Prototype.js (for example Prototype ships a broken version of JSON). Using something like Array.prototype.map.toString() is a quick and easy way to see if native prototype methods have been tampered with or not.

Hopefully we could use something more clear like [censored code] to indicate that this function would not be truly native code.

[bathos]

It makes more sense if you read [native code] as this function cannot be serialized. This is what it effectively came to mean. AFAIK, the string [native code] arose first as a convention ‘organically’. It wasn’t specified until ES2019, which was a codify-what-already-happened sort of thing, not a let’s-design-something-perfect sort of thing.

Previously the requirement was that toString had to return syntactically invalid source for any unserializable function (note the two identifiers in a row) and this is just the string agents landed on for doing that. Already, functions which cannot be serialized includes functions that aren’t actually native:

• Bound function objects (foo.bind()) hold a pointer to an ES function rather than ‘native’ code, but they cannot be serialized. Therefore they get the [native code] result.
• Functions exported from WASM don’t have ES source, but their source isn’t native, either. Regardless, because they can’t be serialized, they get the [native code] result.

This isn’t to argue against your suggested alternative, which could stand on its own — I’m just attempting to answer the question in the title of the thread. If viewing this proposal as ‘make it possible to declare a function as unserializable,’ it would follow that [native code] would be in the returned string.

One of the use cases for implementation hiding is to help enable creation of Web IDL APIs, whose constructors/methods/etc are normally all unserializable, in the ES layer. I don’t know how much value is placed on this, but [censored code] (or anything else which isn’t [native code]) would fail to address that.

[garvank]

Thanks for the response and context! I appreciate it.

It sounds like a possible solution could be to label truly unserializable in the ES layer as [native code], but JS that's simply opted in using "hide implementation" could be something like[censored code], [private code], or [hidden code].

[michaelficarra]

@garvank That would defeat the purpose of this proposed directive for the "appear as a built-in" use-case. [native code] will mean that you're not going to get the code you asked for, whether it's because the request was refused or was impossible to fulfil.