Remove Deno.customInspect symbol at 2.0

[kt3k]

We're going to deprecate Deno.customInspect symbol in favor of Symbol.for("Deno.customInspect") in #10035

This issue is for tracking the future removal of Deno.customInspect.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[nayeemrmn]

We're going to deprecate Deno.customInspect symbol in favor of Symbol.for("Deno.customInspect")

@kt3k I want to revive the idea of using just "denoCustomInspect" for the key instead. This was my original proposal in #9294 but I didn't push for it at the time. However it came up on discord and others also found the current pattern strange: https://discord.com/channels/684898665143206084/688040863313428503/868555515729436692, https://discord.com/channels/684898665143206084/688040863313428503/868628683227824198.

Symbol.for("Deno.customInspect") was an illogical compromise between unique symbol which is non-polluting but non-compatible, and a string convention which is cross-compatible but polluting. The pollution is a mainly theoretical concern either way which would affect any compatible solution including Symbol.for("Deno.customInspect"). A string convention is far more traditional and has less friction.

"Deno.customInspect" instead of "denoCustomInspect" is also an option, though personally I don't think the Deno namespace aesthetic is important enough to warrant requiring quotes to declare it.

[kt3k]

I think non unique symbols are still less polluting than string keys because symbol keys are always non enumerable even when it is set to the object directly. If we set "denoCustomInspect" directly to the object, that appears in enumeration, and that can be annoying.

It seems a common pattern recently to use symbols for some special protocols eg. Symbol.iterator, Symbol.asyncIterator. So using symbol here express better the idea that this is a special protocol, not a usual function. So I prefer to keep this as a symbol.

[nayeemrmn]

I think non unique symbols are still less polluting than string keys because symbol keys are always non enumerable even when it is set to the object directly. If we set "denoCustomInspect" directly to the object, that appears in enumeration, and that can be annoying.

Most of the time it will be used on a class though. Even if it was set directly on an object and was enumerable, I'm not convinced that's ever a problem. It would only be as bad as implementing .toString(). I think when users are concerned about enumerability to this extent, they are deliberate and use Object.defineProperties().

It seems a common pattern recently to use symbols for some special protocols eg. Symbol.iterator, Symbol.asyncIterator. So using symbol here express better the idea that this is a special protocol, not a usual function.

These are actually unique symbols whose references are built into the language. They are more like Deno.customInspect but don't have a compatibility problem. They act as protocol implementations because they are unique. Symbol.for("Deno.customInspect") doesn't fulfil that purpose or convey that meaning, the feedback I've seen is confusion.