Fixing potential links into docs.scala-lang

heathermiller · heathermiller · commit b2d9ae407851 · 2017-08-02T10:55:30.000+02:00
diff --git a/_tour/abstract-types.md b/_tour/abstract-types.md
@@ -10,6 +10,8 @@ num: 23
 next-page: compound-types
 previous-page: inner-classes
 prerequisite-knowledge: variance, upper-type-bound
+
+redirect_from: "/tutorials/tour/abstract-types.html"
 ---
 
 Traits and abstract classes can have an abstract type member. This means that the concrete implementations define the actual type. Here's an example:
diff --git a/_tour/annotations.md b/_tour/annotations.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 32
 next-page: default-parameter-values
 previous-page: by-name-parameters
+
+redirect_from: "/tutorials/tour/annotations.html"
 ---
 
 Annotations associate meta-information with definitions. For example, the annotation `@deprecated` before a method causes the compiler to print a warning if the method is used.
diff --git a/_tour/basics.md b/_tour/basics.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 2
 next-page: unified-types
 previous-page: tour-of-scala
+
+redirect_from: "/tutorials/tour/basics.html"
 ---
 
 In this page, we will cover basics of Scala.
diff --git a/_tour/by-name-parameters.md b/_tour/by-name-parameters.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 31
 next-page: annotations
 previous-page: operators
+
+redirect_from: "/tutorials/tour/by-name-parameters.html"
 ---
 
 _By-name parameters_ are only evaluated when used. They are in contrast to _by-value parameters_. To make a parameter called by-name, simply prepend `=>` to its type.
diff --git a/_tour/case-classes.md b/_tour/case-classes.md
@@ -10,6 +10,8 @@ num: 11
 next-page: pattern-matching
 previous-page: currying
 prerequisite-knowledge: classes, basics, mutability
+
+redirect_from: "/tutorials/tour/case-classes.html"
 ---
 
 Case classes are like regular classes with a few key differences which we will go over. Case classes are good for modeling immutable data. In the next step of the tour, we'll see how they are useful in [pattern matching](pattern-matching.html).
diff --git a/_tour/classes.md b/_tour/classes.md
@@ -11,6 +11,8 @@ next-page: traits
 previous-page: unified-types
 topics: classes
 prerequisite-knowledge: no-return-keyword, type-declaration-syntax, string-interpolation, procedures
+
+redirect_from: "/tutorials/tour/classes.html"
 ---
 
 Classes in Scala are blueprints for creating objects. They can contain methods,
diff --git a/_tour/compound-types.md b/_tour/compound-types.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 24
 next-page: self-types
 previous-page: abstract-types
+
+redirect_from: "/tutorials/tour/compound-types.html"
 ---
 
 Sometimes it is necessary to express that the type of an object is a subtype of several other types. In Scala this can be expressed with the help of *compound types*, which are intersections of object types.
diff --git a/_tour/currying.md b/_tour/currying.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 10
 next-page: case-classes
 previous-page: nested-functions
+
+redirect_from: "/tutorials/tour/currying.html"
 ---
 
 Methods may define multiple parameter lists. When a method is called with a fewer number of parameter lists, then this will yield a function taking the missing parameter lists as its arguments.
diff --git a/_tour/default-parameter-values.md b/_tour/default-parameter-values.md
@@ -10,6 +10,8 @@ num: 33
 next-page: named-arguments
 previous-page: annotations
 prerequisite-knowledge: named-arguments, function syntax
+
+redirect_from: "/tutorials/tour/default-parameter-values.html"
 ---
 
 Scala provides the ability to give parameters default values that can be used to allow a caller to omit those parameters.
diff --git a/_tour/extractor-objects.md b/_tour/extractor-objects.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 16
 next-page: for-comprehensions
 previous-page: regular-expression-patterns
+
+redirect_from: "/tutorials/tour/extractor-objects.html"
 ---
 
 An extractor object is an object with an `unapply` method. Whereas the `apply` method is like a constructor which takes arguments and creates an object, the `unapply` takes an object and tries to give back the arguments. This is most often used in pattern matching and partial functions.
diff --git a/_tour/for-comprehensions.md b/_tour/for-comprehensions.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 17
 next-page: generic-classes
 previous-page: extractor-objects
+
+redirect_from: "/tutorials/tour/for-comprehensions.html"
 ---
 
 Scala offers a lightweight notation for expressing *sequence comprehensions*. Comprehensions have the form `for (enumerators) yield e`, where `enumerators` refers to a semicolon-separated list of enumerators. An *enumerator* is either a generator which introduces new variables, or it is a filter. A comprehension evaluates the body `e` for each binding generated by the enumerators and returns a sequence of these values.
diff --git a/_tour/generic-classes.md b/_tour/generic-classes.md
@@ -10,6 +10,8 @@ num: 18
 next-page: variances
 previous-page: for-comprehensions
 assumed-knowledge: classes unified-types
+
+redirect_from: "/tutorials/tour/generic-classes.html"
 ---
 Generic classes are classes which take a type as a parameter. They are particularly useful for collection classes.
 
diff --git a/_tour/higher-order-functions.md b/_tour/higher-order-functions.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 8
 next-page: nested-functions
 previous-page: mixin-class-composition
+
+redirect_from: "/tutorials/tour/higher-order-functions.html"
 ---
 
 Scala allows the definition of higher-order functions. These are functions that _take other functions as parameters_, or whose _result is a function_. Here is a function `apply` which takes another function `f` and a value `v` and applies function `f` to `v`:
diff --git a/_tour/implicit-conversions.md b/_tour/implicit-conversions.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 27
 next-page: polymorphic-methods
 previous-page: implicit-parameters
+
+redirect_from: "/tutorials/tour/implicit-conversions.html"
 ---
 
 An implicit conversion from type `S` to type `T` is defined by an implicit value which has function type `S => T`, or by an implicit method convertible to a value of that type.
diff --git a/_tour/implicit-parameters.md b/_tour/implicit-parameters.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 26
 next-page: implicit-conversions
 previous-page: self-types
+
+redirect_from: "/tutorials/tour/implicit-parameters.html"
 ---
 
 A method with _implicit parameters_ can be applied to arguments just like a normal method. In this case the implicit label has no effect. However, if such a method misses arguments for its implicit parameters, such arguments will be automatically provided.
diff --git a/_tour/inner-classes.md b/_tour/inner-classes.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 22
 next-page: abstract-types
 previous-page: lower-type-bounds
+
+redirect_from: "/tutorials/tour/inner-classes.html"
 ---
 
 In Scala it is possible to let classes have other classes as members. As opposed to Java-like languages where such inner classes are members of the enclosing class, in Scala such inner classes are bound to the outer object. Suppose we want the compiler to prevent us, at compile time, from mixing up which nodes belong to what graph. Path-dependent types provide a solution.
diff --git a/_tour/local-type-inference.md b/_tour/local-type-inference.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 29
 next-page: operators
 previous-page: polymorphic-methods
+
+redirect_from: "/tutorials/tour/local-type-inference.html"
 ---
 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.
 
diff --git a/_tour/lower-type-bounds.md b/_tour/lower-type-bounds.md
@@ -10,6 +10,8 @@ num: 21
 next-page: inner-classes
 previous-page: upper-type-bounds
 prerequisite-knowledge: upper-type-bounds, generics, variance
+
+redirect_from: "/tutorials/tour/lower-type-bounds.html"
 ---
 
 While [upper type bounds](upper-type-bounds.html) limit a type to a subtype of another type, *lower type bounds* declare a type to be a supertype of another type. The term `B >: A` expresses that the type parameter `B` or the abstract type `B` refer to a supertype of type `A`. In most cases, `A` will be the type parameter of the class and `B` will be the type parameter of a method.
diff --git a/_tour/mixin-class-composition.md b/_tour/mixin-class-composition.md
@@ -10,6 +10,8 @@ num: 6
 next-page: higher-order-functions
 previous-page: traits
 prerequisite-knowledge: inheritance, traits, abstract-classes, unified-types
+
+redirect_from: "/tutorials/tour/mixin-class-composition.html"
 ---
 Mixins are traits which are used to compose a class.
 
diff --git a/_tour/named-arguments.md b/_tour/named-arguments.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 34
 previous-page: default-parameter-values
 prerequisite-knowledge: function-syntax
+
+redirect_from: "/tutorials/tour/named-arguments.html"
 ---
 
 When calling methods, you can label the arguments with their parameter names like so:
diff --git a/_tour/nested-functions.md b/_tour/nested-functions.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 9
 next-page: currying
 previous-page: higher-order-functions
+
+redirect_from: "/tutorials/tour/nested-functions.html"
 ---
 
 In Scala it is possible to nest function definitions. The following object provides a `factorial` function for computing the factorial of a given number:
diff --git a/_tour/operators.md b/_tour/operators.md
@@ -10,6 +10,8 @@ num: 30
 next-page: by-name-parameters
 previous-page: local-type-inference
 prerequisite-knowledge: case-classes
+
+redirect_from: "/tutorials/tour/operators.html"
 ---
 In Scala, operators are methods. Any method with a single parameter can be used as an _infix operator_. For example, `+` can be called with dot-notation:
 ```
diff --git a/_tour/pattern-matching.md b/_tour/pattern-matching.md
@@ -11,6 +11,8 @@ num: 12
 next-page: singleton-objects
 previous-page: case-classes
 prerequisite-knowledge: case-classes, string-interpolation, subtyping
+
+redirect_from: "/tutorials/tour/pattern-matching.html"
 ---
 
 Pattern matching is a mechanism for checking a value against a pattern. A successful match can also deconstruct a value into its constituent parts. It is a more powerful version of the `switch` statement in Java and it can likewise be used in place of a series of if/else statements.
diff --git a/_tour/polymorphic-methods.md b/_tour/polymorphic-methods.md
@@ -10,7 +10,9 @@ num: 28
 
 next-page: local-type-inference
 previous-page: implicit-conversions
-prerequisite-knowledge: unified-types,
+prerequisite-knowledge: unified-types
+
+redirect_from: "/tutorials/tour/polymorphic-methods.html"
 ---
 
 Methods in Scala can be parameterized by type as well as value. The syntax is similar to that of generic classes. Type parameters are declared within a pair of brackets while value parameters are enclosed in a pair of parentheses.
diff --git a/_tour/regular-expression-patterns.md b/_tour/regular-expression-patterns.md
@@ -10,6 +10,8 @@ num: 15
 
 next-page: extractor-objects
 previous-page: singleton-objects
+
+redirect_from: "/tutorials/tour/regular-expression-patterns.html"
 ---
 
 Regular expressions are strings which can be used to find patterns (or lack thereof) in data. Any string can be converted to a regular expression using the `.r` method.
diff --git a/_tour/self-types.md b/_tour/self-types.md
@@ -10,6 +10,8 @@ num: 25
 next-page: implicit-parameters
 previous-page: compound-types
 prerequisite-knowledge: nested-classes, mixin-class-composition
+
+redirect_from: "/tutorials/tour/self-types.html"
 ---
 Self-types are a way to declare that a trait must be mixed into another trait, even though it doesn't directly extend it. That makes the members of the dependency available without imports.
 
diff --git a/_tour/sequence-comprehensions.md b/_tour/sequence-comprehensions.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 17
 next-page: generic-classes
 previous-page: extractor-objects
+
+redirect_from: "/tutorials/tour/sequence-comprehensions.html"
 ---
 
 Scala offers a lightweight notation for expressing *sequence comprehensions*. Comprehensions have the form `for (enumerators) yield e`, where `enumerators` refers to a semicolon-separated list of enumerators. An *enumerator* is either a generator which introduces new variables, or it is a filter. A comprehension evaluates the body `e` for each binding generated by the enumerators and returns a sequence of these values.
diff --git a/_tour/singleton-objects.md b/_tour/singleton-objects.md
@@ -10,6 +10,8 @@ num: 13
 
 next-page: regular-expression-patterns
 previous-page: pattern-matching
+
+redirect_from: "/tutorials/tour/singleton-objects.html"
 ---
 
 Methods and values that aren't associated with individual instances of a [class](classes.html) belong in *singleton objects*, denoted by using the keyword `object` instead of `class`.
diff --git a/_tour/tour-of-scala.md b/_tour/tour-of-scala.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 1
 
 next-page: basics
+
+redirect_from: "/tutorials/tour/tour-of-scala.html"
 ---
 
 Scala is a modern multi-paradigm programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages.
diff --git a/_tour/traits.md b/_tour/traits.md
@@ -10,6 +10,8 @@ num: 5
 next-page: mixin-class-composition
 previous-page: classes
 assumed-knowledge: expressions, classes, generics, objects, companion-objects
+
+redirect_from: "/tutorials/tour/traits.html"
 ---
 
 Traits are used to share interfaces and fields between classes. They are similar to Java 8's interfaces. Classes and objects can extend traits but traits cannot be instantiated and therefore have no parameters.
diff --git a/_tour/unified-types.md b/_tour/unified-types.md
@@ -10,6 +10,8 @@ num: 3
 next-page: classes
 previous-page: basics
 prerequisite-knowledge: classes, basics
+
+redirect_from: "/tutorials/tour/unified-types.html"
 ---
 
 In Scala, all values have a type, including numerical values and functions. The diagram below illustrates a subset of the type hierarchy.
diff --git a/_tour/upper-type-bounds.md b/_tour/upper-type-bounds.md
@@ -9,6 +9,8 @@ categories: tour
 num: 20
 next-page: lower-type-bounds
 previous-page: variances
+
+redirect_from: "/tutorials/tour/upper-type-bounds.html"
 ---
 
 In Scala, [type parameters](generic-classes.html) and [abstract types](abstract-types.html) may be constrained by a type bound. Such type bounds limit the concrete values of the type variables and possibly reveal more information about the members of such types. An _upper type bound_ `T <: A` declares that type variable `T` refers to a subtype of type `A`.
diff --git a/_tour/variances.md b/_tour/variances.md
@@ -9,6 +9,8 @@ partof: scala-tour
 num: 19
 next-page: upper-type-bounds
 previous-page: generic-classes
+
+redirect_from: "/tutorials/tour/variances.html"
 ---
 
 Variance is the correlation of subtyping relationships of complex types and the subtyping relationships of their component types. 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, whereas the lack of variance can restrict the reuse of a class abstraction.
