Proposal: allow variance annotations on input positions

⭐ Suggestion

I would like the in and out type modifiers to be able to applied to a generic type when it is being instantiated.

This would function by expanding the type by eliminating fields that are in violation of the requested constraint.

This might be thought of as another form of anonymous type mapping.

For example the code that can currently be written as

interface BivariantSetLike {
    size: number;
}
interface CovariantSetLike<out T> extends BivariantSetLike {
    getAll: () => Iterable<T>;
}
interface ContravariantSetLike<in T> extends BivariantSetLike {
    add: (key: T) => void;
}
interface SetLike<in out T>
    extends CovariantSetLike<T>,
        ContravariantSetLike<T>,
        BivariantSetLike {
    constrain: (key: T) => T | undefined
}

declare const dogs: SetLike<Dog>;
const animals: CovariantSetLike<Animal> = dogs;
const poodles: ContravariantSetLike<Poodle> = dogs;
const countable: BivariantSetLike = dogs;

Could instead be written as

interface SetLike<in out T> {
    size: number;
    getAll: () => Iterable<T>;
    add: (key: T) => void;
    constrain: (key: T) => T | undefined;
}

declare const dogs: SetLike<Dog>;
const animals: SetLike<-in Animal> = dogs;
const poodles: SetLike<-out Poodle> = dogs;
const countable: SetLike<-in -out void> = dogs;

I'm not opposed to allowing the non-negated forms to be used in type instantiations, but in line with the existing pattern that in and out already don't impose variance restrictions on otherwise variant code: I think the positive forms, if they are even syntactically allowed, should always no-op. So MyType<T> == MyType<in T> == MyType<out T> == MyType<in out T>

readonly and writeonly

field: -in T -> readonly field: T
field: -out T -> set field(value: T)
readonly field: -in T -> readonly field: T
readonly field: -out T -> (field is skipped)
set field(value: -in T) -> (field is skipped)
set field(value: -out T) -> set field(value: T)

This would break for an index signature type like {[n: number]: T} for -out T, because there is no syntax to describe a writeonly [n: number].
Perhaps, instead of simplifying types to remove the -in ReifiedT, it is just legal to use the -in and -out modifiers anywhere a type is legal inside of an object type, and it just impacts the semantics of the type.
If this were the case, it would be legal to write something like {x: -in number} as an alias for {readonly x: number}. I'm not particularly fond of this option, but it does provide an elegant answer for lacking writeonly.

Strict Methods

TypeScript treats methods and functions differently when it comes to variance (assuming --strictFunctionTypes, which is table stakes for any use of the in out modifiers anyway). I think the special treatment of methods should be ignored when using this new syntax, as it largely defeats the purpose. So WritableFunction and WritableMethod will remain distinct, but T1 and T2 ought to be be identical:

interface WritableFunction<T> {
    write: (value: T) => void;
}
interface WritableMethod<T> {
    write(value: T): void;
}

type T1 = WritableFunction<-in number>;
type T2 = WritableMethod<-in number>;

The alternative is to make a --strictMethodTypes flag that enables method type checking everywhere.
This proposal's syntax would, I believe, allow for things like Array to be mostly usable, despite their non-variance.

🔍 Search Terms

Variance covariance contravariance bivariance in out input

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

Issue không nêu tên các tệp triển khai hoặc các bài kiểm thử. Hãy bắt đầu bằng cách xác định các đường dẫn kiểm tra kiểu và khởi tạo generic của TypeScript, sau đó so sánh chúng với các ví dụ về variance, readonly/writeonly, index-signature và strict-method. Công việc được xem là hoàn tất khi đã thống nhất về ngữ nghĩa của các phương án và các bài kiểm thử của trình biên dịch bao quát cú pháp được đề xuất.