No need for Symbol to be visible on Module Namespace

[bmeck]

A variety of Symbols can be used to change behaviors but are not always exposed / used for exotic objects:

class X {};
Object.setPrototypeOf(X, null);

// undefined, true
console.log(X[Symbol.hasInstance], new X() instanceof X);

[ljharb]

The entire reason for this proposal is because the committee did not want magic behavior for Namespace objects; they wanted a general-purpose solution.

[jdalton]

The entire reason for this proposal is because the committee did not want magic behavior for Namespace objects; they wanted a general-purpose solution.

I don't think these are mutually exclusive. Taking Bradley's example where functions have some unexposed behavior there's also user-facing parts like Symbol.hasInstance and even a proxy trap. So while parts can be unexposed other parts can be exposed.

[devsnek]

what people seemed to want was a consistent way to be able to explain why object X isn't behaving like object Y. the most obvious way to go about that with the current mechanics we have available seemed to me to be a symbol.

[jdalton]

I don't see it specified in this proposal but is the idea that for namespace objects it would be non-enumerable, non-configurable, non-writable like the namespace @@toStringTag?

[devsnek]

@jdalton yeah; its not in the readme but i put it in spec.html: https://gus.host/proposal-symbol-thenable/#sec-@@thenable

[ljharb]

That's more of a stage 2 concern, but yes, I would imagine so - module namespace objects are meant to be fully immutable.

(edit: sorry, closed by accident)