Improved support for read-only arrays and tuples

[Anders Hejlsberg (ahejlsberg)]

This PR improves our support for read-only arrays and tuples:

• readonly modifier on array types: readonly T[] corresponds to ReadonlyArray<T> (similar to how T[] corresponds to Array<T>).
• readonly modifier on tuple types: readonly [T0, T1, ...] correponds to a tuple type that derives from ReadonlyArray<T0 | T1 | ...> and has read-only element positions.
• Support for read-only arrays and tuples in mapped types. When a mapped type specifies a +readonly modifier, read-write array and tuple types are mapped to their read-only form, and when a mapped type specifies a -readonly modifier, read-only array types and tuples are mapped to their read-write form. This means that Readonly<T> now produces read-only forms of arrays and tuples.

Some examples:

functionf1(mt: [number,number],rt: readonly[number,number]){mt[0]=1;// Okrt[0]=1;// Error, read-only element}functionf2(ma: string[],ra: readonlystring[],mt: [string,string],rt: readonly[string,string]){ma=ra;// Errorma=mt;// Okma=rt;// Errorra=ma;// Okra=mt;// Okra=rt;// Okmt=ma;// Errormt=ra;// Errormt=rt;// Errorrt=ma;// Errorrt=ra;// Errorrt=mt;// Ok}typeReadWrite<T>={-readonly[PinkeyofT] : T[P]};typeT0=Readonly<string[]>;// readonly string[]typeT1=Readonly<[number,number]>;// readonly [number, number]typeT2=Partial<Readonly<string[]>>;// readonly (string | undefined)[]typeT3=Readonly<Partial<string[]>>;// readonly (string | undefined)[]typeT4=ReadWrite<Required<T3>>;// string[]

Fixes#26864.
Fixes#28540.
Fixes#28968.

[Jordi Oliveras Rovira (j-oliveras)]

Typo: typle to tuple.

[Anders Hejlsberg (ahejlsberg)]

Jordi Oliveras Rovira (@j-oliveras) Oops. Thanks!

[Sheetal Nandi (sheetalkamat)]

Add test for this?

[Sheetal Nandi (sheetalkamat)]

Think we need test/handling for .d.ts generation and decorator for this new typeNode kind.

[Jessica Franco (Jessidhia)]

Does this improved support for readonly arrays mean it's now possible to have readonly array/tuples as the type of a rest argument?

function f(...args: ReadonlyArray<string>) {} is currently a type error.

[Anders Hejlsberg (ahejlsberg)]

@Kovensky Isn't in the PR currently, but I see no reason why we couldn't support it. I will fix it, it's just a minor change.

[Ryan Cavanaugh (RyanCavanaugh)]

+1 for .d.ts emit coverage - the only .d.ts currently in this set has semantic errors in its originating file, which makes it shaky at best

[Sheetal Nandi (sheetalkamat)]

I think having decorator test is good idea too.. since we normally forget that when we enable new kind of type annotation.

[Ryan Cavanaugh (RyanCavanaugh)]

// @emitDecoratorMetadata: true// @experimentalDecorators: true// @declaration: truedeclareconstsomeDec: any;classA{
@someDecj: readonlystring[];
@someDeck: readonly[string,number];}

[Anton Lobov (zhuravlikjb)]

Is this an intended change that a single 'readonly' is no longer parsed as a type?
Such code compiled fine before this change:

type readonly = string;
var q: readonly;

(This is not a sample from real code, just a test case.)

Seems that it is not a serious issue, but would be nice to know if this was planned, as you still may declare a type named 'readonly' but cannot use it anymore.

[Anders Hejlsberg (ahejlsberg)]

Anton Lobov (@zhuravlikjb) No, that was not intended. I will look at getting it fixed.

[Klaus Meinhardt (ajafff)]

Using a version of TypeScript that contains this PR creates declaration files which are not compatible with older versions of TypeScript.

In case someone else has the same problem: I created a transformer to downlevel readonly array types in declaration files: https://github.com/ajafff/ts-transform-readonly-array

[falsandtru (falsandtru)]

Anders Hejlsberg (@ahejlsberg) This feature leaved some large bugs (Maybe regression). Please fix them: #29442#29702

[Anders Hejlsberg (ahejlsberg)]

falsandtru (@falsandtru) Those issues are not related to this PR, but I have a fix in #29740.

[falsandtru (falsandtru)]

Indeed, I thought another PR. Anyway, thanks for fixing.

[Simon Buchan (simonbuchan)]

I assume the extension to readonly SomeObject or readonly T is not worth the native compiler support, now that Readonly<T> can work for everything as expected? React.Ref<readonly T> such that it's assignable from Ref<U> for U extends T would be kind of neat though.

[Felix Becker (felixfbecker)]

Is it still possible to declare a writable property with an immutable array? For example, constructable stylesheets defines document.adoptedStyleSheets as an array that is immutable and needs to be reassigned to be changed:

element.shadowRoot.adoptedStyleSheets=[...element.shadowRoot.adoptedStyleSheets,styleSheet]