My Go Resolutions for 2017

Re:My Go Resolutions for 2017 by whateveracct on Thursday January 19, 2017 @02:40PM (#13438819)

I'd say "yes" only because this concept will exist whether or not you have a name for it. And it's a concept you will bump into in any language with any sort of generics (even Go [1])

I wrote Scala for the last 2 years and was the resident type system "expert", so I had to explain variance to people pretty often. Luckily, it's a pretty quick, mathy definition:

Some notation first:

    A <: B means "A is a subtype of B"
    A >: B means "A is a supertype of B"
    F[_] refers to a unary type constructor.

Now for the definitions:

    If F[_] is "covariant", it means that if A <: B, then F[A] <: F[B]
    If F[_] is "contravariant", it means that if A >: B, then F[B] <: F[A]

Examples of covariant type constructors are List and Functions in their output. An example of a contravariant type constructor is Functions in their input type.

^ This is all that needs to be said! I can write it on a whiteboard in ~5 minutes. I'd say that's a reasonable thing to be expected to learn.

[1] https://www.reddit.com/r/golang/comments/3gtg3i/passing_slic...

[ Parent | on HN ]

Re:My Go Resolutions for 2017 by bshanks on Sunday January 22, 2017 @06:13AM (#13454696)

i think the way you defined it, covariant and contravariant are identical; in your contravariant definition, swap the names of "A" and "B" and you get:

  if B >: A, then F[A] <: F[B]

and B >: A means the same as A <: B, so this means:

  if A <: B, then F[A] <: F[B]

which is the same as your covariant definition.

Perhaps you meant:

    If F[_] is "contravariant", it means that if A <: B, then F[B] <: F[A]

?

[ Parent | on HN ]