Proposal: allow variance annotations on input positions

[DavidANeil]

⭐ 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

[RyanCavanaugh]

What's the intended behavior of these when a structural comparison occurs instead of a variance-based one?

[DavidANeil]

I'm not totally certain on how the structure should be modified. I think just deleting the fields from the type seems simplest.
But maybe leaving the fields and marking them as some form of never makes more sense, but never isn't quite right because then the types wouldn't really ever be assignable to each other.

[RyanCavanaugh]

I don't quite get how this is supposed to extend out. Like let's say you had

interface Foo<T> {
  bar(): {
    prop: T;
    other: string;
  }
}

it seems like it should still be legal to write

function qua(x: Foo<-out number>) {
  const m = x.bar().other;
}

since you're not doing anything to violate covariant-on-T use of x here

[DavidANeil]

It would expand to:

{
    bar(): {
        prop: -out number;
        other: string;
    }
}

which would resolve to

{
    bar(): {
        set prop(value: number);
        other: string;
    }
}

Which would, correctly, allow accessing bar().other