Suggestion: Derive disposability checks from known symbols rather than global interfaces

[Renegade334]

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

When it comes to checking for disposability (for use with using/await using declarations), the checker fetches the global Disposable/AsyncDisposable symbol and runs an assignability test against its type.

This is mostly fine, but this interface is user-mutable, so any script in the project which plays with these interfaces can unintentionally modify the checker's behaviour. For example, a module might declare an empty global interface for backwards compatibility:

declare global {
  interface Disposable {}
}

export interface MyResource extends Disposable {
  ...
}

...which means that all disposability tests will now return true within the checker, if there's no lib.esnext.disposable or similar to populate the interface.

Other checker processes that rely on well-known symbols tend to interrogate the symbol-keyed properties directly, rather than test against global types – for example, iteration checks first fetch the well-known Symbol.iterator via getPropertyNameForKnownSymbolName, then use this index to access the iteration method on the target type.

While not critical, it would be an improvement if the checker could test against the Symbol.dispose/Symbol.asyncDispose properties directly, rather than testing for assignability against the global interface.