Improved support for read-only arrays and tuples

[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:

function f1(mt: [number, number], rt: readonly [number, number]) {
    mt[0] = 1;  // Ok
    rt[0] = 1;  // Error, read-only element
}

function f2(ma: string[], ra: readonly string[], mt: [string, string], rt: readonly [string, string]) {
    ma = ra;  // Error
    ma = mt;  // Ok
    ma = rt;  // Error
    ra = ma;  // Ok
    ra = mt;  // Ok
    ra = rt;  // Ok
    mt = ma;  // Error
    mt = ra;  // Error
    mt = rt;  // Error
    rt = ma;  // Error
    rt = ra;  // Error
    rt = mt;  // Ok
}

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

type T0 = Readonly<string[]>;  // readonly string[]
type T1 = Readonly<[number, number]>;  // readonly [number, number]
type T2 = Partial<Readonly<string[]>>;  // readonly (string | undefined)[]
type T3 = Readonly<Partial<string[]>>;  // readonly (string | undefined)[]
type T4 = ReadWrite<Required<T3>>;  // string[]

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

[j-oliveras]

Typo: typle to tuple.

[ahejlsberg]

@j-oliveras Oops. Thanks!

[sheetalkamat]

Add test for this?

[sheetalkamat]

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

[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.

[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.

[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

[sheetalkamat]

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

[RyanCavanaugh]

// @emitDecoratorMetadata: true
// @experimentalDecorators: true
// @declaration: true

declare const someDec: any;
class A {
  @someDec
  j: readonly string[];
  @someDec
  k: readonly [string, number];
}

[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.

[ahejlsberg]

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

[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]

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

[ahejlsberg]

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

[falsandtru]

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

[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.

[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]