Covariance / Contravariance Annotations

[Igorbek]

(It's a question as well as a suggestion)

Update: a proposal #10717

I've supposed that for structural type system as TypeScript is, type variance isn't applicable since type-compatibility is checked by use.

But when I had read @RyanCavanaugh 's TypeScript 1.4 sneak peek (specifically 'Stricter Generics' section) I realized that there's some lack in this direction by design or implementation.

I wondered this code is compiled:

function push<T>(arr: T[], a: T) { arr.push(a); }
var ns = [1];
push<{}>(ns, "a"); // ok, we added string to number[];

More clear code:

interface A { a: number; }
interface B extends A { b: number; }
interface C extends B { c: number; }

var a: A, b: B, c: C;

var as: A[], bs: B[];

as.push(a); // ok
as.push(b); // ok, A is contravariant here (any >=A can be pushed) 

bs.push(a); // error, B is contravariant here, so since A<B, A cannot be pushed -- fair 
bs.push(b); // ok
bs.push(c); // ok, C>=B

as = bs; // ok, covariance used?

as.push(a); // ok, but actually we pushed A to B[]

How could B[] be assignable to A[] if at least on member push is not compatible. For B[].push it expects parameters of type B, but A[].push expects A and it's valid to call it with A.

To illustrate:

var fa: (a: A) => void;
var fb: (b: B) => void;

fa(a); fa(b);
fb(a); // error, as expected
fa = fb; // no error
fa(a); // it's fb(a)

Do I understand it correctly that is by design?
I don't think it can be called type-safe.

Actually, such restriction that could make B[] to be unassignable to A[] isn't desirable.
To solve it I suggest to introduce variance on some level (variable/parameter, type?).

Syntax

var as: A[]; // no variance
var bs: out B[]; // covariant, for "read"
<out A[]>bs; // ok, covariance used
<A[]>bs; // same is before, out should be inferred

(<A[]>bs)[0]; // means, allow to get covariant type
(<A[]>bs).push(a); // means, disallow to pass covariant type

<in A[]>bs; // fails

function push<T>(data: in T[], val: out T): void {
 data.push(val);
}
push(animals, dog); // allowed, T is Animal
push(dogs, animal); // disallow, T can't be inferred

// In opposite
function find<T>(data: out T[], val: out T): bool { ... } // allow only get from data
find(animals, dog); // allowed
find(cats, dog); // allowed T can be inferred as Mammal

I'm not sure where variance should be applied - to variable or type?
Looks like it closer to variable it self, so the syntax could be like:

var in a: number[];
function<T>(in a: T[], out b: T): { ... }

Questions to clarification

• inference variance from usage (especially for functions)
• is it applicable for types (like C# uses for interfaces/delegates)
• how to describe variance on member-level (does it need?)
• can variable be in out (fixed type)?
• can variable be neither in nor out (open for upcast/downcast)?

So this topic is a discussion point.

[danquirk]

The assignments you've noted are by design. When checking assignability of function types their parameters are considered bivariant. So when assigning fa = fb it is valid if fa's parameters are assignable to fb's or vice versa. Likewise for the function typed members of Array when determining whether as = bs is valid. See #274 for the suggestion to check these more strictly all the time.

Co/contravariance is not an easy concept for a lot of folks to grasp (even though there is an intuitive nature to the assignment questions). Explicit annotations for them can be especially difficult for people to make use of (particularly if they have to author the annotations in their own code). C# has these types of annotations now but was highly successful for many years without the additional layer of checking the variance annotations afford. My gut feeling is that I would be surprised if these ended up in TypeScript given their complexity and how 'heavy' a concept they are.

[MgSam]

@danquirk I disagree that covariance/contravariance are such "heavy" concepts. In practice, it's generally just library authors that use them (not end users), and they're easy to ignore, so I don't think you're adding a burden to the language. Yet on the flip side, you're adding a lot of expressiveness to situations that would otherwise be less type safe.

Also, at a syntax level- having optional keywords of "in" and an "out" seems to me to be as lightweight as language constructs get.

I certainly wouldn't consider this feature high enough priority to want it added to the backlog anytime soon, but once TypeScript is more mature it could certainly be a useful addition.

[Igorbek]

So, if go with some "strict" mode only, there's no way to annotate variance, because it shouldn't introduce any new keywords.
I believe in most cases, TypeScript will be able to infer variance from usage. And bivariance for functions could be a fallback if modifier wouldn't be specified.

I've read Function Argument Bivariance article, and it looks like the example might be rewritten more clear and useful without bivariance requirement:

enum EventType { Mouse, Keyboard }

interface Event { timestamp: number; }
interface MouseEvent extends Event { x: number; y: number }
interface KeyEvent extends Event { keyCode: number }

function listenEvent<TEvent extends Event>(eventType: EventType, handler: (n: TEvent) => void) {
 /* ... */
}

listenEvent<MouseEvent>(EventType.Mouse, e => console.log(e.x + ',' + e.y));

@MgSam thanks for support.

[metaweta]

Outputs are always covariant and arguments are usually contravariant. The only point where we'd need an annotation is when an argument is also used as an output. I think it would be a lot easier to grasp if all type constructors and generics came equipped with their associated map functions, since then you just look at what order the mapped functions get applied.

[Igorbek]

@metaweta callbacks are bivariant now. It also needs clarification/make stricter.

[metaweta]

I don't know what you mean by "callbacks are bivariant": variance is a concept that applies to a specific use of a type in a signature. I was suggesting that types used in arguments be contravariant by default; now that I think more about it, that would cause new errors in currently working code, which is unacceptable.

To avoid the issue of a new keyword, I suggest using +/- like Scala does.

How about a directive "use variance" to opt into that assumption? That way a library author can avoid having to add the contravariant modifier everywhere, while the user of the library doesn't have to worry about it. Directives are a part of ECMAScript specifically designed for this kind of scoped alteration of semantics.

[Igorbek]

I mean that callback is an argument which is a function:

class A { ... } class B extends A { ... } class C extends B { ... }
function f(callback: (b: B) => void) { ... }
f((x: A) => { ... }); // no error, callback accepts x: A, fair any B is A
f((x: C) => { ... }); // no error, callback accepts x: C, but it might be called with B which isn't C

That's what "callback are bivariant" means.

Regarding +/-, do you mean to use it with type specifier? Like:

function f<T>(x: T-[], y: T) { x.push(y); } // y: T+, by default for function arguments

Directives are a part of ECMAScript specifically designed for this kind of scoped alteration of semantics.

Which directives do you mean?

[metaweta]

The arrow functor is contravariant in its first argument and covariant in its second. Contravariance acts somewhat like multiplication by -1.

In (a:A) => B, A is contravariant and B is covariant.

In (f: (a: A) => B) => C, C is covariant and (a: A) => B is contravariant, which means that A is covariant (-1 * -1 = 1) and B is contravariant (-1 * 1 = 1).

Regarding +/-, do you mean to use it with type specifier?

I mean to use it in the type parameters rather than the function signature:

interface Foo <-A, +B> {
 map<+C>(f:(a:A) => C): Foo<C, B>;
}

Which directives do you mean?

The directive "use strict" changes the semantics of the language within a function block or program production (usually an HTML script block). I imagine a "use variance" directive in a module production.

[Igorbek]

The arrow functor is contravariant in its first argument and covariant in its second. Contravariance acts somewhat like multiplication by -1.

I understand this. But now TS violates this rule in case of callbacks. I didn't say how it should work, I did say how it works now.

[metaweta]

Yikes! That's terrible.

[RyanCavanaugh]

If function parameters weren't bivariant, Array<Dog> would not be a structural subtype of Array<Animal> due to members like forEach.

[metaweta]

I take back my "that's terrible" assesment; that would only be fair for a purely functional language. Every mutable data structure is going to have this trouble. Getters are covariant while setters are contravariant: given f:(x:X)=>Y, and arr:Array<X>, arr.map(f) is an array where a getter returns a Y; for instance, this could be implemented lazily by having a getter look up an element x and then return f(x). A map using X contravariantly would take a function g:(w: W)=>X and arr.comap(g) would be an array where the setter would store g(w) in the array. (I'm not suggesting comap be implemented or that map have a different implementation, just pointing out how the variance shows up in getters and setters.)

I think the article's right that the sound alternatives are too cumbersome for not enough benefit.