address review comments

Author: martijnhoekstra

_tour/variances.md

@@ -10,7 +10,7 @@ previous-page: generic-classes
 redirect_from: "/tutorials/tour/variances.html"
 ---
 
-Variance is a property of parameterized types that relates the subtyping relationship of parameterized types to the subtyping releationship of its type parameter. Scala supports variance annotations of type parameters of [generic classes](generic-classes.html), to allow them to be covariant, contravariant, or invariant if no annotations are used. The use of variance in the type system allows us to make intuitive connections between complex types.
+Variance lets you control how type parameters behave with regards to subtyping. Scala supports variance annotations of type parameters of [generic classes](generic-classes.html), to allow them to be covariant, contravariant, or invariant if no annotations are used. The use of variance in the type system allows us to make intuitive connections between complex types.
 
 ```scala mdoc
 class Foo[+A] // A covariant class
@@ -20,7 +20,7 @@ class Baz[A]  // An invariant class
 
 ### Invariance
 
-By default, type paramters in scala are invariant: subtyping relationships between the type paramter aren't reflected in the parameterized type. To explore why this works the way it does, we look at a simple parameterized type, the mutable box.
+By default, type parameters in Scala are invariant: subtyping relationships between the type parameters aren't reflected in the parameterized type. To explore why this works the way it does, we look at a simple parameterized type, the mutable box.
 
 ```scala mdoc
 class Box[A](var content: A)
@@ -39,27 +39,27 @@ case class Dog(name: String) extends Animal
 We can say that `Cat` is a subtype of `Animal`, and that `Dog` is also a subtype of `Animal`. That means that the following is well-typed:
 
 ```scala mdoc
-  val myAnimal: Animal = Cat("felix")
+  val myAnimal: Animal = Cat("Felix")
 ```
 
-What about boxes? If I have a `Box[Cat]`, is it a subtype of `Box[Animal]`, like `Cat` is a subtype of `Animal`? At first sight, it looks like that may be plausible, but if we try to do that, the compiler will tell us we have an error:
+What about boxes? Is `Box[Cat]` a subtype of `Box[Animal]`, like `Cat` is a subtype of `Animal`? At first sight, it looks like that may be plausible, but if we try to do that, the compiler will tell us we have an error:
 
 ```scala
-  val myCatBox: Box[Cat] = new Box[Cat](Cat("felix"))
+  val myCatBox: Box[Cat] = new Box[Cat](Cat("Felix"))
   val myAnimalBox: Box[Animal] = myCatBox // this doesn't compile
   val myAnimal: Animal = myAnimalBox.content
 ```
 
 Why could this be a problem? We can get the cat from the box, and it's still an Animal, isn't it? Well, yes. But that's not all we can do. We can also replace the cat in the box with a different animal
 
 ```scala
-  mayAnimalBox.content = Dog("fido")
+  mayAnimalBox.content = Dog("Fido")
 ```
 
-There now is a Dog in the Animal box. That's all fine, you can put Dogs in Animal boxes, because Dogs are Animals. But our Animal Box is a Cat Box! You can't put a Dog in a Cat box. If we could, and then try to get the cat from our catbox, it would turn out to be a dog, breaking type soundness.
+There now is a Dog in the Animal box. That's all fine, you can put Dogs in Animal boxes, because Dogs are Animals. But our Animal Box is a Cat Box! You can't put a Dog in a Cat box. If we could, and then try to get the cat from our Cat Box, it would turn out to be a dog, breaking type soundness.
 
 ```scala
-  val myCat: Cat = myCatBox.content //myCat would be fido the dog!
+  val myCat: Cat = myCatBox.content //myCat would be Fido the dog!
 ```
 
 From this, we have to conclude that `Box[Cat]` and `Box[Animal]` can't have a subtyping relationship, even though `Cat` and `Animal` do.
@@ -100,7 +100,7 @@ printAnimalNames(dogs)
 
 ### Contravariance
 
-We've seen we can accomplish Covariance by making sure that we can't put something in the Covariant type, but only get something out. What if we had the opposite, something you can put something in, but can't take out? This situation arises if we have something like a serializer, that takes values of type A, and converts them to a serialized format.
+We've seen we can accomplish covariance by making sure that we can't put something in the covariant type, but only get something out. What if we had the opposite, something you can put something in, but can't take out? This situation arises if we have something like a serializer, that takes values of type A, and converts them to a serialized format.
 
 ```scala mdoc
   abstract class Serializer[-A] {
@@ -122,4 +122,4 @@ More formally, that gives us the reverse relationship: given some `class Contra[
 
 Variance is supported in different ways by some languages that are similar to Scala. For example, variance annotations in Scala closely resemble those in C#, where the annotations are added when a class abstraction is defined (declaration-site variance). In Java, however, variance annotations are given by clients when a class abstraction is used (use-site variance).
 
-Scalas tendency towards immutable types makes it that covariant and contravariant types are more common than in other languages, since a mutabable generic type can't be covariant or contravariant.
+Scala's tendency towards immutable types makes it that covariant and contravariant types are more common than in other languages, since a mutable generic type must be invariant.