Syntax for type cortion of for..in loop variable

[antoinep92]

Suggestion

🔍 Search Terms

for..in iterator typing cast coertion

✅ Viability Checklist

My suggestion meets these guidelines:

• 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 feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Because of the flexibility of javascript, typescript can only safely infer object keys as strings, although in most cases a more precise type is what makes sense. Currently there are several workarounds, but all of the ways I can think of are too verbose and emit unnecessary runtime code.

I propose to introduce a syntax to restrict the type of the for..in variable:

for(let iterator as KeyType in iterable)

The as underlined the fact that it is an unsafe cast, but the syntax is compact.

📃 Motivating Example

Consider this example using this feature:

interface Data { a?: number, b?: number, c?: number }
function copy(data: Data) {
  const out: Data = {};
  for(const key as keyof Data in data)
    out[key] = data[key]
  return out;
}

💻 Use Cases

Currently, the example above can be implemented using a duplicate variable:

interface Data { a?: number, b?: number, c?: number }
function copy(data: Data) {
  const out: Data = {};
  for(const key in data) {
    const k = key as keyof Data;
    out[k] = data[k];
  }
  return out;
}

Or the iterator may be coerced to a narrower type using an assertion:

interface Data { a?: number, b?: number, c?: number }
function castKey<T>(key: PropertyKey): asserts key is keyof T {}
function copy(data: Data) {
  const out: Data = {};
  for(const key in data) {
    castKey<Data>(key);
    out[key] = data[key];
  }
  return out;
}

In both case, the code is rather verbose and arguably a bit technical for the second one, considering this is a rather common use-case. Also some unnecessary js code will be emitted, although it probably has negligible performance impact, I still find it would be cleaner to address this at the typescript level.

[RyanCavanaugh]

Duplicate #3500

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.