why `.disposeAsync` and not `.dispose`?

[ljharb]

The "async" suffix might make sense when the two methods are alongside each other, but this is already an AsyncDisposableStack instance. Why not just use .dispose?

[rbuckton]

I'm generally of the opinion that most async operations in a standard library should be named such, even when there isn't a need to differentiate. The exception to that is methods on something like Promise, where it's usually obvious such operations are async. There are far too many API methods in Nodejs and in the DOM that don't follow that pattern, and I've often seen them used incorrectly under the assumption that the methods did something synchronously instead, leading to race conditions.

More clearly describing the behavior is helpful not only to code writers, but to code readers and reviewers. If we only used dispose(), it's far harder for a reviewer to spot the missing await in something like this:

async function shutdown(stack) {
  ... 
  stack.dispose();
  ... 
} 

Also, naming it disposeAsync here more clearly indicates that it is the only async operation on the object. use, et al., are sync operations.

[ljharb]

Other than Array.fromAsync (which isn't stage 4 yet), we don't have such a precedent in the language.

I see your point about differentiating from the other operations which are sync, but i'm not sure if using a form of hungarian notation is a sufficient substitute for reading the docs, or using types.

[rbuckton]

This kind of differentiation is fairly common in many languages, with or without type systems. The proposed Atomics.waitAsync also follows this naming convention.

I'm stating that we should establish such a precedent in the language. Potentially even a formalized API design guideline for built-ins.