mikeash.com pyblog/friday-qa-2015-11-20-covariance-and-contravariance.html comments

J2 - 2021-04-08 13:10:58

Thu, 08 Apr 2021 13:10:58 GMT

There is an error:

"This is another key rule: functions are subtypes of other functions if the parameter types are supertypes and the return types are subtypes."

Should be

"This is another key rule: functions are subtypes of other functions if the parameter types are subtypes and the return types are supertypes."

mikeash - 2017-09-23 23:41:29

Sat, 23 Sep 2017 23:41:29 GMT

My guess is just that there are higher priorities and they haven't gotten around to it yet. That's the answer for a lot of "obvious" features the language doesn't have. It's still pretty young.

Oleg - 2017-09-23 20:44:41

Sat, 23 Sep 2017 20:44:41 GMT

Hi Mike.
Could you please explain/guess why in swift it was decided to use invariant generics? For me it is wierd, i've tried to use some of my obj-c code with generics (that involves subtyping) via bridging in swift and it gets useless without casts. I wonder isn't swift compiler wise enough to infer generic type variance?

mikeash - 2016-06-08 01:54:25

Wed, 08 Jun 2016 01:54:25 GMT

Right, the first line works, the second line doesn't.

Saurav Nagpal - 2016-06-06 10:04:18

Mon, 06 Jun 2016 10:04:18 GMT

Hi Mike

let returnsCat: () -> Cat = animalF

I think this will not work. Because return Cat is subtype of function animalF. As you said superTypes cannot substitute subtypes.

Spud - 2015-12-11 20:33:08

Fri, 11 Dec 2015 20:33:08 GMT

the way you wrote:

let returnsCat: () -> Cat = animalF

and started the following paragraph "All of this works in Objective-C too,d" made me think that was legal. suggest putting a comment beside it like // illegal

VinDuv - 2015-11-23 12:36:19

Mon, 23 Nov 2015 12:36:19 GMT

There is an interesting problem with generic collection covariance: it potentially allows objects of the wrong type to be inserted in the collection.

I’m told that the first version of Java had covariant arrays without sufficient protection, which allowed to downcast objects without compile time or runtime checks:



// Cat is a subclass of Animal

Cat[] cats = ...;

Animal[] animals = cats; // Array covariance is allowed

animals[0] = new Dog(); // Putting a Dog into an array of Animal: no complaint from the compiler, no runtime check

Cat cat = cats[0]; // We try to get a Cat from the array of Cat but it’s a Dog!

cat.purr(); // invalid method call, will probably crash the JVM

On current Java implementations, the above code still compiles, but the assignation to animals[0] fails with an ArrayStoreException.

Fortunately, with Swift’s copy-on-write arrays, this code is perfectly fine: the assignment of animals[0] will create a copy of the array, so cats will still only contain Cats.

Maybe this Array-specific feature could be provided to custom generic container types, but I’m not sure if it’s doable in a “safe” (compiler-checked) manner.

Sven - 2015-11-22 10:36:28

Sun, 22 Nov 2015 10:36:28 GMT

I believe subtype and supertype are mixed up in the Generics section as well. Method return types and r/o properties should be subtypes and method parameters should be supertypes, right?

mikeash - 2015-11-21 18:00:20

Sat, 21 Nov 2015 18:00:20 GMT

J: Thanks, fixed now. This stuff still does mix me up sometimes.

Matthew Cheok: It looks like protocols don't support changing types at all. If you take a protocol that inherits from another protocol and try to "override" the super-protocol's function with one that has different types, Swift just treats it as a new function regardless of variance. You can try this code to see:



class Thing {}

class Animal: Thing {}

class Cat: Animal {}



protocol SuperP {

    func f(animal: Animal) -> Animal

}



protocol SubP1: SuperP {

    func f(thing: Thing) -> Cat

}



protocol SubP2: SuperP {

    func f(cat: Cat) -> Thing

}



class ImplementsSubP1: SubP1 {

    func f(thing: Thing) -> Cat {

        return Cat()

    }

}



class ImplementsSubP2: SubP2 {

    func f(cat: Cat) -> Thing {

        return Thing()

    }

}

Neither of the two classes are considered to fully implement the protocols. If you add a second f to each class that's Animal -> Animal then it works.

Matthew Cheok - 2015-11-21 16:58:15

Sat, 21 Nov 2015 16:58:15 GMT

Suppose the discussion for subclass applies to protocols as well? Thanks for this! It's succinct and easily digestible. I find it more helpful to replace A, B and C with something I'm more familiar with like NSObject, UIView and UILabel.

J - 2015-11-21 16:22:07

Sat, 21 Nov 2015 16:22:07 GMT

I think "subtype" and "supertype" are reversed in the Standalone Functions section

Applied here, the above code works if A is a subtype of C, and if B is a supertype of D.

should be

Applied here, the above code works if A is a supertype of C, and if B is a subtype of D.

Kyle McAlpine - 2015-11-21 11:45:33

Sat, 21 Nov 2015 11:45:33 GMT

Thanks for this Mike! Just as I posted a SO question on this topic! Haha!

http://stackoverflow.com/questions/33752968/swift-cast-generic-type-into-same-generic-type-but-with-a-subclass-of-associate/33759858#33759858

Rick - 2015-11-20 22:09:06

Fri, 20 Nov 2015 22:09:06 GMT

Even more complex and subtle: part of the deal with __covariant showing up in ObjC and NSArray might be compatibility/bridging with Swift.

Swift generics are normally invariant, but the Swift standard library collection types — even though those types appear to be regular generic types — use some sort of magic inaccessible to mere mortals that lets them be covariant.

Take a look... here's a quick concrete example of invariant generic types in Swift:



import UIKit



class Thing<T> { // could be a struct just as well

    var thing: T

    init(_ thing: T) { self.thing = thing }

}

var foo: Thing<UIView> = Thing(UIView())

var bar: Thing<UIButton> = Thing(UIButton())

foo = bar // error: cannot assign value of type 'Thing<UIButton>' to type 'Thing<UIView>'

But Array lets you do the same thing without error:



var views: Array<UIView> = [UIView()]

var buttons: Array<UIButton> = [UIButton()]

views = buttons

(Note that if you tried to assign buttons = views instead, you'd get an error: Swift collections are covariant, not contravariant or bivariant.)

George Kulakowski - 2015-11-20 16:57:43

Fri, 20 Nov 2015 16:57:43 GMT

Nice post!

You're right that bivariance doesn't come up much in Swift (or Java or...). All you could do with a bivariant type parameter is use it to construct other bivariant generic types, or to not use it (and why might you want to do that?).

https://people.cs.umass.edu/~yannis/variance-extended2011.pdf talks about variance, and 3.3 about a setting where bivariant types could come into play, with recursive types. It's pretty readable, as these things go.

https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/markers-variance.md and https://github.com/rust-lang/rfcs/blob/master/text/0738-variance.md talk about variance in Rust, where the interactions with lifetimes make things a bit more interesting. (I'm not sure how up-to-date these are, may not reflect Rust today, etc.)