From debcb80f2f2b7c50f2ef3a09f85af0fd7d84d43e Mon Sep 17 00:00:00 2001 From: k0ala Date: Thu, 14 Dec 2017 15:19:43 +0100 Subject: [PATCH] Fix typos in documentation: reference > other new features --- docs/docs/reference/inline.md | 8 ++++---- docs/docs/reference/multiversal-equality.md | 7 +++---- docs/docs/reference/named-typeargs.md | 6 +++--- docs/docs/reference/trait-parameters.md | 4 ++-- 4 files changed, 12 insertions(+), 13 deletions(-) diff --git a/docs/docs/reference/inline.md b/docs/docs/reference/inline.md index be686c79a6e5..fd42ac1e14b4 100644 --- a/docs/docs/reference/inline.md +++ b/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 diff --git a/docs/docs/reference/multiversal-equality.md b/docs/docs/reference/multiversal-equality.md index 0e42756d80cb..5a01d8943c56 100644 --- a/docs/docs/reference/multiversal-equality.md +++ b/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). diff --git a/docs/docs/reference/named-typeargs.md b/docs/docs/reference/named-typeargs.md index 60973b7bdc83..431b78bb52e2 100644 --- a/docs/docs/reference/named-typeargs.md +++ b/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. diff --git a/docs/docs/reference/trait-parameters.md b/docs/docs/reference/trait-parameters.md index 050bb515cab9..e2d28c855599 100644 --- a/docs/docs/reference/trait-parameters.md +++ b/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). \ No newline at end of file +For more info, see [Scala SIP 25](http://docs.scala-lang.org/sips/pending/trait-parameters.html).