Typos (twice the same) in Tour of Scala : Variances

[QuentinCazelles]

In section "Covariance":

We say that ImmutableBox is covariant in A, and this is indicated by the + before the A.

More formally, that gives us the following relationship: given some class Cov[+T], then if A is a subtype of B, Cov[A] is a subtype of Cov[B]. This allows us to make very useful and intuitive subtyping relationships using generics.

In section "Contravariance":

We say that Serializer is contravariant in A, and this is indicated by the - before the A. A more general serializer is a subtype of a more specific serializer.

More formally, that gives us the reverse relationship: given some class Contra[-T], then if A is a subtype of B, Contra[B] is a subtype of Contra[A].

---

As stated in "Generic classes":

One convention is to use the letter A as type parameter identifier, though any parameter name may be used.

---

class Cov[+T] should be class Cov[+A].

class Contra[-T] should be class Contra[-A].

---

For context:

• Starting Scala
• Started Tour from beginning, never met generic defined with T letter
• In Java, convention is to use letter T instead of A as in Scala 3 (I think this is main reason for this issue.)

Not really sure with this. I can make a PR when confirmed.

Thanks

[julienrf]

Hey, thank you for opening this issue. In that specific case, I would argue it is preferable not to use a type variable named A in the definition of Cov and Contra, to not confuse it with the type A mentioned afterward (“if A is a subtype of B”).

In the definition of Cov,

class Cov[+T]

T is a type parameter, which is later instantiated to A in the example:

Cov[A]

Here, A is not a type parameter, but a concrete type.

Maybe the confusion comes from the fact that we use A and B for concrete types although in the “Generic classes” pages we say that these names are conventionally used for type parameters.

So, I see the following possible ways forward:

• use names other than A and B in the explanation. For instance, we could use T1 and T2, or Base and Sub, or maybe X and Y?
• keep things as they are. Personally, I like the names A and B here, it makes the sentence “if A is a subtype of B, then Cov[A] is a subtype of Cov[B]” easier to read than “If Sub is a subtype of Base, then Cov[Sub] is a subtype of Cov[Base]”, but that is probably highly subjective.