readonly mapped type modifiers for Map / ReadonlyMap

[bjchambers]

Search Terms

ReadonlyMap
ReadWrite
Writable

Suggestion

3.4.0-rc introduced the ability to use readonly mapped type modifiers with arrays.

(https://devblogs.microsoft.com/typescript/announcing-typescript-3-4-rc/)

It would be useful if the same syntax worked on

Use Cases

This is useful in any library dealing with immutable versions of types. It would allow mapped types to easily convert between Map and ReadonlyMap.

Examples

type ReadWrite<T> = { -readonly [P in keyof T]: T[P] };
const map: ReadWrite<ReadonlyMap<string, string>> = new Map();

map.put('a', 'c'); // this should work, since readonly has been removed.

type Readonly<T> = { readonly [P in keyof T]: T[P] };
const map: Readonly<Map<string, string>> = new Map();

map.put('a', 'c'); // this should not work, since readonly has been applied

Similar examples using Array instead of Map didn't work before 3.4 and did work afterwards.

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

[JakeTunaley]

This would actually be a breaking change if someone is using a type like Readonly<Map<Foo, Bar>>, because right now methods like Map.prototype.put exist on that type, but after this change they would not.

Also, instead of just adding a special case for Map, why not do this in general?

class SomeClass {
    public readonly readonlyField: any;
    public mutableField: any;

    public get property (): any {}
    public set property (value: any) {}

    public set propertyOnlySet (value: any) {}

    public readonly readonlyMethod () {}
    public mutationMethod () {}
}

// Readonly<SomeClass> will be the same as:
class SomeClass {
    public readonly readonlyField: any;
    public readonly mutableField: any;

    public get property (): any {}

    public readonly readonlyMethod () {}
}

That would be incredibly useful, though it would benefit from a new error checking that readonly methods don't mutate class state.

class SomeClass {
    public mutableField: any;

    public set property (value: any) {}

    public mutationMethod () {}

    public readonly readonlyMethod () {
        this.mutableField = 0; // Error: Cannot mutate a property inside a readonly method
        this.property = 0; // Error: Cannot mutate a property inside a readonly method
        this.mutationMethod(); // Error: Cannot call a non-readonly instance method from inside a readonly method
    }
}

[bjchambers]

Hmm... you are correct that it has the potential to break existing code. However, it seems like the same argument would apply to the following change, which made similar changes to ReadonlyArray:

#29435