Suggestion: assigning index signature to object with optional properties should error if value types mismatch

Suggestion

Moving this here from a Twitter discussion with @RyanCavanaugh: https://twitter.com/SeaRyanC/status/1359194486601994241

🔍 Search Terms

• index signature
• partial
• optional

✅ 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

Currently this does not error:

const a: { [key: string]: string } = { foo: 'bar' };
// Expected error here but got none
const t: { foo?: number } = a;
// Runtime type is `string`
// TS type is `number | undefined` ❌
console.log(t.foo);

https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhgLhgbxgbQNYFMCeToBOAlmAOYC6+UxZMAvjALwowBmIISA5AEZwFd6AbgBQAejEwAogA8ADlmBQsAExhYCBEARgALDVhg8ArrFIhYYcFhGhIsKElTsQAfiRhjAWx4b6TeFEJGAAlYzAoIi9DKBwFGCIIGAADQhJSZPFJABU4w0SUzx8-AB8YcJUsVhJVZJhAGXJbcAgQABssADpWkFIACigOlwBKUSA

My suggestion is simply that TypeScript should error at the point when we try to assign the index signature type to the object that has an optional property:

// My suggestion: this should error
const t: { foo?: number } = a;

📃 Motivating Example

Currently we could run into exceptions at runtime. Example:

const a: { [key: string]: string } = { foo: 'bar' };
// Expected error here but got none
const t: { foo?: number } = a;
// Runtime exception ❗️
t.foo?.toExponential();

https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhgLhgbxgbQNYFMCeToBOAlmAOYC6+UxZMAvjALwowBmIISA5AEZwFd6AbgBQAejEwAogA8ADlmBQsAExhYCBEARgALDVhg8ArrFIhYYcFhGhIsKElTsQAfiRhjAWx4b6TeFEJGAAlYzAoIi9DLBlgLDlI8BhAdXJAeD+RKAA6F1csqBBZOWsIojgAGwAKAEohIA

💻 Use Cases

This is my real world use case:

I have a type that represents URL query parameters before they have been validated/decoded:

type QueryParams = {
    [key: string]: string | string[];
};

I also have a type that represents query parameters after they have been validated/decoded:

type QueryData = {
    userId?: number;
};

I have some functions which expect QueryData, but it's very easy to make the mistake of passing in QueryParams instead.

declare const redirectToUserPage: (queryData: QueryData) => void;

declare const queryParams: QueryParams;
declare const queryData: QueryData;

// This is a mistake but TS produces no error
redirectToUserPage(queryParams);
// We should have passed in `queryData` instead

Inizia riproducendo i due esempi di TypeScript Playground e leggendo gli scenari di assegnabilità della proposta per le firme di indice, le proprietà opzionali e i tipi di valore non corrispondenti. Il lavoro è completato quando le assegnazioni non sicure vengono rifiutate con un errore di tipo appropriato, mentre il comportamento richiesto rimane coerente con le regole di compatibilità esistenti di TypeScript.