Add --strictAssignments flag to prevent unsafe code from aliasing assignments

[kevinbarabash]

Search Terms

microsoft#1394 is related but suggests adding new keywords whereas this feature request doesn't require new keywords.

Suggestion

Add a --strictAssignments flag which would force all variables appearing on the right side of an assignment expression to be invariant with the corresponding type on the left side of an assignment expression. If the left size is readonly, the assignment will be treated as covariant.

Use Cases

This feature would be helpful when writing safe code by protecting against mutating arrays or objects to contain data that doesn't match the defined type. This can cause runtime errors when using an object of a different type while assuming it was the original type.

// Motivating example
class Animal {}
class Cat { purr() {} }
class Dog { bark() {} }

const cats: Cat[] = [new Cat];
const animals: Animal[] = cats;

animals.push(new Dog);
cats.forEach(cat => cat.purr());  // TypeError thrown: .purr() not present on cat

Examples

// Arrays
const cats: Cat[] = [new Cat];

const animals: Animal[] = cats; // error: alias assignments are invariant
const animals: Animal[] = [new Cat];  // okay: covariant is safe since source is a literal
const animals: ReadonlyArray<Animal> = cats; // okay: covariant is safe since target is readonly

// Simple objects
type CatNode = { animal: Cat };
type AnimalNode = { animal: Animal };

const catNode: CatNode = { animal: new Cat };

const animalNode: AnimalNode = catNode; // error
const animalNode: AnimalNode = { animal: new Cat }; // okay
const animalNode: AnimalNode = { animal: cat }; // okay
const animalNode: Readonly<AnimalNode> = catNode;  // okay

// Nested objects
type CatsNode = { animals: Cat[] };
type AnimalsNode = { animals: Animal[] };
type ReadonlyAnimalsNode = { animals: ReadonlyArray<Animal> };

const catsNode: CatNode = { animals: [new Cat] };
const cats: Cat[] = [new Cat];

const animalsNode: AnimalNode = catsNode; // error
// prevents animalsNode.animals = [new Dog] which would conflict 
// with CatsNode's definition of its animals property

const animalsNode: AnimalNode = { animal: [new Cat] }; // okay
// okay since we're not storing [new Cat] in a variable typed as a Cat[]

const animalsNode: AnimalNode = { animal: cats }; // error
// prevents animalsNode.animals.push(new Dog) which would add
// a Dog to cats array

const animalsNode: ReadonlyAnimalsNode = { animals: cats }; // okay
// okay since the animals property is a readonly array and we are unable
// to add new elements to it.

const animalsNode: ReadonlyAnimalsNode = catsNode; // error
// prevents animalsNode.animals = [new Dog] which would conflict 
// with CatsNode's definition of its animals property

const animalsNode: Readonly<ReadonlyAnimalsNode> = catsNode; // okay
// prevents both setting animals property to different from Cats[] and
// prevents adding a Dog to the animals array which is typed as a Cats[]
// on the right side

const animalsNode: Readonly<AnimalsNode> = catsNode;  // error
// while making AnimalsNode readonly prevents the reassignment of animals
// to something other than Cat[], it's still possible to push a Dog to catsNode's
// animals array.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code. This change is opt in except for users using --strict would get this behavior. My assumption in this is that users wanting strict behavior would probably appreciate additional checks that improve safety.

• This wouldn't change the runtime behavior of existing JavaScript code. This is a compile time check only. It doesn't affect the output of the emitter.

• This could be implemented without emitting different JS based on the types of the expressions. No change to emitter output.

• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)

• This feature would agree with the rest of TypeScript's Design Goals. In particular it checks the "Produce a language that is composable and easy to reason about." box. The fact that we can write code that will subvert guarantees about the types stored within variables and objects make it hard to reason about code.