Rewrote local type inference tour

Author: travissarles

tutorials/tour/_posts/2017-02-13-local-type-inference.md

@@ -9,48 +9,41 @@ categories: tour
 num: 29
 next-page: operators
 previous-page: polymorphic-methods
+prerequisite-knowledge: unified-types, generic-classes
 ---
-Scala has a built-in type inference mechanism which allows the programmer to omit certain type annotations. It is, for instance, often not necessary in Scala to specify the type of a variable, since the compiler can deduce the type from the initialization expression of the variable. Also return types of methods can often be omitted since they correspond to the type of the body, which gets inferred by the compiler.
+The Scala compiler can often infer the type of a value so you don't have to declare it explicitly. You'll often see this with variables and return types.
 
-Here is an example:
-
-```tut
-object InferenceTest1 extends App {
-  val x = 1 + 2 * 3         // the type of x is Int
-  val y = x.toString()      // the type of y is String
-  def succ(x: Int) = x + 1  // method succ returns Int values
-}
+## Omitting the type
+```
+val businessName = "Montreux Jazz Café"
+```
+The compiler can detect that `businessName` is a String. It works similarly with methods:
 ```
+def squareOf(x: Int) = x * x
+```
+The compiler can infer that the return type is an int so no return type is required.
 
 For recursive methods, the compiler is not able to infer a result type. Here is a program which will fail the compiler for this reason:
 
 ```tut:fail
-object InferenceTest2 {
-  def fac(n: Int) = if (n == 0) 1 else n * fac(n - 1)
-}
+def fac(n: Int) = if (n == 0) 1 else n * fac(n - 1)
 ```
 
 It is also not compulsory to specify type parameters when [polymorphic methods](polymorphic-methods.html) are called or [generic classes](generic-classes.html) are instantiated. The Scala compiler will infer such missing type parameters from the context and from the types of the actual method/constructor parameters.
 
-Here is an example which illustrates this:
-
+Here are two examples:
 ```
 case class MyPair[A, B](x: A, y: B);
-object InferenceTest3 extends App {
-  def id[T](x: T) = x
-  val p = MyPair(1, "scala") // type: MyPair[Int, String]
-  val q = id(1)              // type: Int
-}
-```
-
-The last two lines of this program are equivalent to the following code where all inferred types are made explicit:
+val p = MyPair(1, "scala") // type: MyPair[Int, String]
 
+def id[T](x: T) = x
+val q = id(1)              // type: Int
 ```
-val x: MyPair[Int, String] = MyPair[Int, String](1, "scala")
-val y: Int = id[Int](1)
-```
+The compiler uses the types of the arguments of `MyPair` to figure out what type `A` and `B` are. Likewise for the type of `x`.
+
+## When not to rely on type inference
 
-In some situations it can be quite dangerous to rely on Scala's type inference mechanism as the following program shows:
+It is generally considered more readable to declare the type of members exposed in a public API. Also, in some situations it can be quite dangerous to rely on Scala's type inference mechanism as the following program shows:
 
 ```tut:fail
 object InferenceTest4 {
@@ -60,4 +53,3 @@ object InferenceTest4 {
 ```
 
 This program does not compile because the type inferred for variable `obj` is `Null`. Since the only value of that type is `null`, it is impossible to make this variable refer to another value.
-