Note that the fundamental concern here is that a Promise-returning [Symbol.dispose]() method is a clear vector for unhandled rejections, whether invoked by an await using or an ordinary using statement.

probably makes most sense for this to be in await-thenable, I think.

@bradzacher
So my thing is, if we do that, how do we also ban

function unhandledRejection() {             
    using _ = {
        async [Symbol.dispose]() {
            throw new Error('dispose error');
        }
    }
}

It doesn't go in await-thenable, since that's all about unnecessary awaiting of non-thenables. Maybe no-misused-promises then? Note that there's no () => Promise<void> to () => void assignment happening here, since the object literal is provided literally to the using declaration, therefore, we'd need to add a new check for using declarations specifically, rather than being able to rely on the existing checks of no-misused-promises.

Does the disposable method have a default type definition? If it does then iirc there's another rule that should already catch it.

If it doesn't then no-misused-promises would probably be a good fit - iirc it already handles array iteration callbacks.

Does the disposable method have a default type definition? If it does then iirc there's another rule that should already catch it.

If it doesn't then no-misused-promises would probably be a good fit - iirc it already handles array iteration callbacks.

After a bit of investigation...

await using sync disposable ✅

await using x = {
    [Symbol.dispose]() { }
}

can be easily added to await-thenable, #10209 in progress.

EDIT: RESOLVED in #10209

Promise returning function assigned to Disposable variable. ✅

const x: Disposable = {
    async [Symbol.dispose]() {}
} 

already flagged by no-misused-promises. This is a garden variety () => Promise<void> to () => void assignment.

Promise returning function in variable assigned to Disposable variable ❌

const x = {
    async [Symbol.dispose]() {}
} 
const y: Disposable = x;

not flagged by current tooling at all. Could/should be added to no-misused-promises (or upcoming strict-void-return, #9707). Arguably this is just an existing hole in the rule for checksVoidReturn that it doesn't inspect the properties within a variable being assigned.

EDIT: Filed #10357

using x with variable ❌

const x = {
    async [Symbol.dispose]() {}
} 
using y = x;

not flagged by current tooling at all (unless an explicit : Disposable type annotation is provided). Could/should be added to no-misused-promises (or upcoming strict-void-return, #9707).

EDIT: Filed #10357

using x with literal ❌

using y = {
    async [Symbol.dispose]() {}
};

not flagged by current tooling at all. Could/should be added to no-misused-promises (or upcoming strict-void-return, #9707).

EDIT: Filed #10357

async disposable class ⏳

class d implements Disposable {
    async [Symbol.dispose]() {}
}

Not flagged by current tooling at all. But it should be, by no-misused-promises's inheritedMethods checks. This is a bug due to the key being a (static) "computed" symbol rather than an identifier. Filed #10211

Closing this issue since #10209 is resolved.

Remaining work is tracked in #10211 and #10357