Fix typos in documentation: reference > other new features

docs/docs/reference/inline.md

@@ -69,9 +69,9 @@ we'd get
 
 instead. This behavior is designed so that calling an inline method is
 semantically the same as calling a normal method: By-value arguments
-are evaluated before the call wherea by-name arguments are evaluated
+are evaluated before the call whereas by-name arguments are evaluated
 each time they are referenced. As a consequence, it is often
-preferrable to make arguments of inline methods by-name in order to
+preferable to make arguments of inline methods by-name in order to
 avoid unnecessary evaluations.
 
 Inline methods can be recursive. For instance, when called with a constant
@@ -114,8 +114,8 @@ overhead:
 Existing Scala defines a `@inline` annotation which is used as a hint
 for the backend to inline. For most purposes, this annotation is
 superseded by the `inline` modifier. The modifier is more powerful
-than the annotation: Expansion is guarenteed instead of best effort,
-it happens in the fronend instead of in the backend, and it also applies
+than the annotation: Expansion is guaranteed instead of best effort,
+it happens in the frontend instead of in the backend, and it also applies
 to method arguments and recursive methods.
 
 Since `inline` is now a keyword, it would be a syntax error to write

docs/docs/reference/multiversal-equality.md

@@ -31,7 +31,7 @@ would not typecheck if an implicit was declared like this for type `T`
 This definition effectively says that value of type `T` can (only) be
 compared with `==` or `!=` to other values of type `T`. The definition
 is used only for type checking; it has no significance for runtime
-behavior, since `==` always maps to `equals` and `!=` alwatys maps to
+behavior, since `==` always maps to `equals` and `!=` always maps to
 the negation of `equals`. The right hand side of the definition is a value
 that has any `Eq` instance as its type. Here is the definition of class
 `Eq` and its companion object:
@@ -63,7 +63,7 @@ other numbers, sequences only comparable to other
 sequences and sets only comparable to other sets.
 
 There's also a "fallback" instance named `eqAny` that allows comparisons
-over all types that do not themeselves have an `Eq` instance.  `eqAny` is
+over all types that do not themselves have an `Eq` instance.  `eqAny` is
 defined as follows:
 
     def eqAny[L, R]: Eq[L, R] = Eq
@@ -102,8 +102,7 @@ The precise rules for equality checking are as follows.
 
     Here _lifting_ a type `S` means replacing all references to  abstract types
     in covariant positions of `S` by their upper bound, and to replacing
-    all refinement types in in covariant positions of `S` by their parent.
-    The purpose if lifte
+    all refinement types in covariant positions of `S` by their parent.
 
 More on multiversal equality is found in a [blog post](http://www.scala-lang.org/blog/2016/05/06/multiversal-equality.html)
 and a [Github issue](https://github.com/lampepfl/dotty/issues/1247).

docs/docs/reference/named-typeargs.md

@@ -3,7 +3,7 @@ layout: doc-page
 title: "Named Type Arguments"
 ---
 
-Type arguments of methods can now be named as well as by position. Example:
+Type arguments of methods can now be named, as well as by position. Example:
 
 
     def construct[Elem, Coll[_]](xs: Elem*): Coll[Elem] = ???
@@ -20,6 +20,6 @@ The main benefit of named type arguments is that they allow some
 arguments to be omitted. Indeed, if type arguments are named, some
 arguments may be left out.  An example is the definition of `xs3`
 above. A missing type argument is inferred as usual by local type
-inference. The same is not true for positional arguments, which have
-to be given always for all type parameters.
+inference. The same is not true for positional arguments, which must always
+be provided for all type parameters.
 

docs/docs/reference/trait-parameters.md

@@ -22,7 +22,7 @@ ambiguities. For instance, you might try to extend `Greeting` twice,
 with different parameters.
 
 ```scala
-/*!*/ class D extends C with Greeting("Bill") // error: parameters passed twice
+/*!*/ class D extends C with Greeting("Bill") // error: parameter passed twice
 ```
 
 Should this print "Bob" or "Bill"? In fact this program is illegal,
@@ -57,4 +57,4 @@ class E extends Greeting("Bob") with FormalGreeting
 
 ### Reference
 
-For more info, see [Scala SIP 25](http://docs.scala-lang.org/sips/pending/trait-parameters.html).
+For more info, see [Scala SIP 25](http://docs.scala-lang.org/sips/pending/trait-parameters.html).