Add a Mutable type (opposite of Readonly) to lib.d.ts

[selmanj]

Search Terms

mutable, mutable type

Suggestion

lib.d.ts contains a Readonly type, but not a Mutable type. This type would be the opposite of Readonly, defined as:

type Mutable<T> = {
  -readonly[P in keyof T]: T[P]
};

Use Cases

This is useful as a lightweight builder for a type with readonly properties (especially useful when some of the properties are optional and conditional logic is needed before assignment).

Examples

 type Mutable<T> = {-readonly[P in keyof T]: T[P]};
 
 interface Foobar {
   readonly a: number;
   readonly b: number;
   readonly x?: string;
 }

 function newFoobar(baz: string): Foobar {
   const foobar: Mutable<Foobar> = {a: 1, b: 2};
   if (shouldHaveAnX(baz)) {
     foobar.x = 'someValue';
   }

   return foobar;
 }

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. new expression-level syntax)

Readonly modifiers "are a joke" (#13002) so this would still compile:

interface I { readonly x: number; readonly y: number; }
type Mutable<T> = {
    -readonly[P in keyof T]: T[P]
};
declare const i: I;
const j: Mutable<I> = i;

[selmanj]

Andy (Andrewkraft) (@Andy-MS) I can see why that would be undesired. Ideally you wouldn't be able to assign i to j here because Mutable<I> strips the readonly modifiers off i, which has been declared to be an I. Note that in my example, we are using Mutable<Foobar> as a shorthand to create a new type that we can freely mutate before returning it as a Foobar. The object instance assigned to variable foobar is never declared to be a type with readonly modifiers.

I don't want to discuss whether or not readonly modifiers are a joke. The language already provides a way to declare a type that removes readonly modifiers. This request is merely asking for a predefined type called Mutable available in typescript rather than having to define your own.

[FDIM]

I'd really like to see this as part of typescript, it is quite useful in unit tests.
We have a copy of this as Writable locally in the project and I also see that angular team has added Readwrite type in their devkit core package (not sure if it is exposed though)

On the other hand I've encountered an issue and I think this type should be

type Mutable<T> = T & {
  -readonly[P in keyof T]: T[P]
}; 

but this does not remove readonly flag and without this you are not able to pass Mutable to a function that accepts Foo if your object has private properties

[jdom]

I have something similar in my codebase, but that covers ReadonlyArray<string> too:

type MutableReadonlyStringArrays<T> = { [P in keyof T]: T[P] extends ReadonlyArray<string> ? string[] : T[P] };
type Mutable<T> = MutableReadonlyStringArrays<{ -readonly [P in keyof T]: T[P] }>;

This can probably be generalized to cover other non-string arrays too, I just didn't have the need in my usage. But thought it would be nice to cover these if it gets into lib.d.ts

[jdom]

I actually had to generalize this, and ended up with the following:

type Mutable<T> = { -readonly [P in keyof T]: T[P] extends ReadonlyArray<infer U> ? U[] : T[P] };

This will make properties of a type mutable, plus also turn properties that are ReadonlyArray<U> as normal arrays of U too. Nevertheless, is there a way to make this recursive too so it applies to nested hierarchies?

[jdaley]

Julian Dominguez (@jdom)

type Mutable<T> = {
    -readonly [P in keyof T]: T[P] extends ReadonlyArray<infer U> ? Mutable<U>[] : Mutable<T[P]>
};

[lirbank]

A DeepMutable would be nice too.

type DeepMutable<T> = { -readonly [P in keyof T]: DeepMutable<T[P]> };

See https://stackoverflow.com/a/43001581/1959584

[baetheus]

I wish the typescript designers had gone with immutability by default instead of mutability. If all properties and variable declarations were readonly by default then I wouldn't have to type readonly so often. Mutable properties could have used a keyword like mutable. It would be much easier to find bugs, just grep -r mutable *.ts for the likely culprits... Or, at the very least, a compiler option to default to readonly instead of mutable would be useful for many projects.

[PreventRage]

I wish the typescript designers had gone with immutability by default instead of mutability. If all properties and variable declarations were readonly by default then I wouldn't have to type readonly so often. Mutable properties could have used a keyword like mutable. It would be much easier to find bugs, just grep -r mutable *.ts for the likely culprits... Or, at the very least, a compiler option to default to readonly instead of mutable would be useful for many projects.

I suspect that would severely break the "JavaScript is valid Typescript" design point

[baetheus]

PreventRage (@PreventRage) How so? The mutable keyword doesn't exist in javascript and a mutability flag in compiler config would cause compiler errors in the same way that the strict flag currently does.

[PreventRage]

Brandon Blaylock (@baetheus) I think technically you have a point. Which I would restate as "The various strict* options already cause valid JS to be invalid TS, so why worry about adding other such?"

My sense is that apply more rigorous rules and force your JS to be cleaner (strict*) is qualitatively different from invert default behavior (immutableByDefault), and that the former exception follows the spirit of the design while the latter does not. But that's now just a sense/opinion on my part, not any kind of proof.

Strangely (perhaps I'm totally contradicting myself?) I find the notion of a way to mark an individual type as immutable (I think just a tidier version of the Readonly<> generic) feels consistent with the design while getting rid of most of the tediously repetitive readonly.

[baetheus]

PreventRage (@PreventRage) Thanks for getting back to me! I understand that immutability is not for everyone, and I often find myself using mutable structures when doing hot path optimization. While I have no particular issues with the argument that immutableByDefault might not be in the spirit of the language as designed, it nevertheless would be useful for me (and probably a few other programmers that I've worked with over the years).

That said, I'm not in earnest expecting that such a feature would be implemented, I mainly meant to put forward a feature that would pair well with the proposed Mutable<T> type outlined in this issue and to gripe about my own feelings on TypeScript. (A good portion of the work I do is the "last 20%" of a project prior to release. Anecdotally, the misuse of mutability in JS and TS is the primary culprit for most project stalls.)

As for using the Readonly<T> generic to achieve immutability, you are right and it is a solution that I've used regularly. My only qualms are that the burden of keeping track of what is immutable is left to the programmer, and not the compiler. Any opportunity of getting the compiler to do more of my job is an opportunity worth taking.

[dhoulb]

I just came across the following minor use case for this:

I'm creating a class with public properties I have marked as readonly, but I want to be able to write to those properties within the class.

The Mutable type provides an understandable way to describe it. The code's tidy enough that I don't mind the type casting:

class MyClass {
    readonly myVal: string;

    set(myVal: string) {
        (this as Mutable<this>).myVal = myVal;
    }
}

In general I think it's a good idea to add this helper type just for parity with Readonly