Defining Symbol.dispose and other symbol methods

With explicit resource management becoming a common pattern in the JS ecosystem, it could be worthwhile to support defining a Symbol.dispose method on custom descriptors to associate custom destructor operations with a given GC object.

Has there been previous discussion of supporting this pattern of resource consumption when working with GC descriptor objects?

There are also other Symbol methods that could be useful to define - Symbol.asyncDispose, Symbol.iterator, Symbol.asyncIterator, Symbol.toStringTag, Symbol.hasInstance and Symbol.toPrimitive (full list - https://tc39.es/ecma262/#sec-well-known-symbols).

A general way to allow these methods could be to support all well known ECMA-262 symbols with either a special bit or a special prefix like @@wellKnownSymbol (the old ecma-262 naming convention for these symbols, new convention is %wellKnownSymbol%). There is then also the question if custom symbols should be supported via Symbol.for('foo'), where that would then need separate design as well. But well-known symbols is likely good enough.

So the main questions seem to be:

• Is Symbol.dispose a use case worth supporting?
• Is supporting all well-known symbols worthwhile, and therefore a general Symbol solution is preferable?
• Should Symbol.for also be supported?

Start by reviewing the ECMA-262 well-known symbols list linked in the issue and the existing custom-descriptor design. Compare the proposed Symbol.dispose, other well-known symbols, and Symbol.for cases, then use the discussion to determine whether a general mechanism is appropriate. Done means an agreed scope and design direction, rather than a defined implementation task.