Should validate iteree when using `using`/`await using` in loop initializer

🔍 Search Terms

explicit resource management, using, await using, loop initializer, Symbol.dispose, Symbol.asyncDispose, iteration

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

In this code,

export function throwsException() {
    for (using x of [1, 2, 3]) {
        console.log(x);
    }
}

I expect to see an error. It doesn't currently show one (playground link)

If I did something like using x = 3; I would get something like The initializer of a 'using' declaration must be either an object with a '[Symbol.dispose]()' method, or be 'null' or 'undefined'. I think a similar error message would be appropriate here too.

📃 Motivating Example

export function throwsException() {
    for (using x of [1, 2, 3]) {
        console.log(x);
    }
}

is preventable exception-throwing code.
And validating it a logical extension of validating

export function throwsException() {
    for (const x of [1, 2, 3]) {
        using y = x; // TS ERROR: The initializer of a 'using' declaration must be either an object with a '[Symbol.dispose]()' method, or be 'null' or 'undefined'
        console.log(x);
    }
}

💻 Use Cases

1. What do you want to use this for? Safer usage explicit resource management features.
2. What shortcomings exist with current approaches? No validation of explicit resource management declarations in loop initializers
3. What workarounds are you using in the meantime? N/A.