Docs: function parameter bivariance #14973

Activity

1. aluanhaddad commented on Apr 2, 2017

   

   Aluan Haddad (aluanhaddad)

   on Apr 2, 2017

   Contributor

   More actions

   Great idea but I'm not sure that the second example fits anymore given that inspiration for the motivating example is now declared safely https://github.com/Microsoft/TypeScript/blob/master/lib/lib.dom.d.ts#L2671
2. PyroVortex commented on Apr 4, 2017

   

   PyroVortex

   on Apr 4, 2017

   More actions

   The first one is not really true anymore either:

   class Animal {
       pet(): void;
   }
   class Dog extends Animal {
       bark(): void;
   }
   class Cat extends Animal {
       meow(): void;
   }
   
   function doSomethingWithAnimals<T extends Animal>(array: T[]): void {
       // The only place this function can get an instance of T is from the array itself, which is safe to add back to the array
       let animal: T = array.pop();
       // The only interface available to interact with T is that of Animal
       animal.meow(); // compilation error
       animal.pet(); // valid
       array.push(animal); // Safe, the item came from the array
   }
   
   function addAnimal<T extends Animal, U extends T>(array: T[], animal: U): void {
       array.push(animal); // Necessarily safe
   }
   
   const dogs: Dog[] = [new Dog()];
   const cats: Cat[] = [new Cat()];
   let animals: Animal[] = dogs; // No need for this to ever be allowed.
   animals = [new Dog(), new Cat()]; // Safe
   doSomethingWithAnimals(dogs); // Valid
   doSomethingWithAnimals(cats); // Valid
   addAnimal(dogs, new Cat()); // Compiler error
   addAnimal(cats, new Dog()); // Compiler error
   addAnimial(dogs, new Dog()); // Valid
   addAnimal(animals, new Dog()); // Valid
   addAnimal(animals, new Cat()); // Valid
3. pkch commented on Apr 4, 2017

   

   Max (pkch)

   on Apr 4, 2017

   Author

   More actions

   Oh very interesting.

   So with both original arguments no longer valid, what reasons remain for function parameter bivariance (as opposed to contravariance that would ensure type safety)? In my, admittedly very limited, understanding of this issue, silently allowing covariance in function arguments opens a non-trivial hole in type safety.
4. Ryan Cavanaugh (RyanCavanaugh)

   added

   QuestionAn issue which isn't directly actionable in codeAn issue which isn't directly actionable in code

   on Apr 4, 2017
5. RyanCavanaugh commented on Apr 4, 2017

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Apr 4, 2017

   Member

   More actions

   If you simply make function parameters contravariant, then you lose a critical property of generics: that Foo<T> is necessarily a subtype of Foo<U> if T is a subtype of U. This is both unintuitive and extremely expensive (all "fast" generic checks now become much slower structural expansions).

   Fundamentally you can't fix this without explicitly differentiating things like Array<T>#indexOf from Array<T>#push - these functions appear to both take a single T and return a number, but need different semantics applied to them to be sound. This also isn't about ReadOnlyArray vs not -- consider 0-argument sort, for example, which doesn't need variance either way but can't be on ReadOnlyArray.
6. pkch commented on Apr 6, 2017

   

   Max (pkch)

   on Apr 6, 2017

   Last edited by pkch

   Author

   More actions

   Ryan Cavanaugh (@RyanCavanaugh) By structural expansions, you mean the type checker would, for each generic class, examine how each of its type variables appears in its methods, and based on that, choose the variance of the class with respect to each type variable? For example, with respect to the type variable that appears only in method return types, the class would be covariant; and with respect to the type variable that appears in both argument and return types, the class would be invariant.

   Is this really very slow? It only needds to be done once per class definition. (Edit: it might make it even faster if the programmer can indicate the variance in generic class definition; then the type checker just needs to verify it.)

   And I can see that it would cause far too many generic classes to end up invariant; but I suppose it's possible to make the class hierarchy a bit more refined, by adding mix-in classes that behave covariantly because they don't have type variables in method arguments.
7. Mohamed Hegazy (mhegazy)

   closed this as completedon Apr 21, 2017
8. microsoft

   locked and limited conversation to collaborators on Jun 21, 2018