diff --git a/_sips/sips/2011-10-12-implicit-classes.md b/_sips/sips/2011-10-12-implicit-classes.md index 61558987aa..084fb7d4a5 100644 --- a/_sips/sips/2011-10-12-implicit-classes.md +++ b/_sips/sips/2011-10-12-implicit-classes.md @@ -30,7 +30,7 @@ argument in its first parameter list. It may also include an additional implicit parameter list. An implicit class must be defined in a scope where method definitions are allowed (not at the top level). An implicit class is desugared into a class and implicit -method pairing, where the implciit method mimics the constructor of +method pairing, where the implicit method mimics the constructor of the class. The generated implicit method will have the same name as the implicit diff --git a/_sips/sips/2012-01-30-value-classes.md b/_sips/sips/2012-01-30-value-classes.md index 4b6a202abd..ec9b91e346 100644 --- a/_sips/sips/2012-01-30-value-classes.md +++ b/_sips/sips/2012-01-30-value-classes.md @@ -136,7 +136,7 @@ is expanded to the following method in the companion object of class `C`: def extension$m($this: C, params): R = body2 -Here `body2` is the same as `body` with each occurence of `this` or `C.this` +Here `body2` is the same as `body` with each occurrence of `this` or `C.this` replaced by `$this`. The original method `m` in `C` will be changed to def m(params): R = C.extension$m(this, params) @@ -214,7 +214,7 @@ will be eliminated again in step 4). The newly generated type is assumed to have no members and to be completely outside the normal Scala class hierarchy. That is, it is a subtype of no other type and is a supertype only of `scala.Nothing`. -We now replace every occurence of the type `C` in a symbol's type or in a tree's +We now replace every occurrence of the type `C` in a symbol's type or in a tree's type annotation by `C$unboxed`. There are however the following two exceptions to this rule: @@ -223,7 +223,7 @@ to this rule: e.isInstanceOf[C] -2. All occurences of methods in class `C` are left unaffected. +2. All occurrences of methods in class `C` are left unaffected. We then re-typecheck the program, performing the following adaptations if types do not match up. diff --git a/_sips/sips/2013-05-31-improved-lazy-val-initialization.md b/_sips/sips/2013-05-31-improved-lazy-val-initialization.md index 19da99e89f..7b3d430d48 100644 --- a/_sips/sips/2013-05-31-improved-lazy-val-initialization.md +++ b/_sips/sips/2013-05-31-improved-lazy-val-initialization.md @@ -679,7 +679,7 @@ For those wishing to reproduce the results, the benchmarking suite takes 90 minu The final result of those benchmarks is that amount proposed versions, the two that worth considering are (V4-general) and (V6). They both perform better than the current implementation in all the contended case. Specifically, in the contended case, V6 is 2 times fater than V1, while V4-general is 4 times faster. -Unfortunately V4-general is 30% slower in the uncontended case than current implemetation(V1), while V6 is in the same ballpark, being up to 5% slower or faster depending on the setup of the benchmark. +Unfortunately V4-general is 30% slower in the uncontended case than current implementation(V1), while V6 is in the same ballpark, being up to 5% slower or faster depending on the setup of the benchmark. Based on this, we propose V6 to be used as default in future versions of Scala. diff --git a/_sips/sips/2014-06-27-42.type.md b/_sips/sips/2014-06-27-42.type.md index 6a1d71c610..fcc021993f 100644 --- a/_sips/sips/2014-06-27-42.type.md +++ b/_sips/sips/2014-06-27-42.type.md @@ -490,7 +490,7 @@ applications which work with large datasets. derivation. Implicit resolution is Scala's mechanism for inferring values from types and in current Scala - shapeless provides a macro-based materialier for instances of its `Witness` type class. This SIP + shapeless provides a macro-based materializer for instances of its `Witness` type class. This SIP adds a directly compiler supported type class as a replacement, ``` diff --git a/_sips/sips/2016-01-11-static-members.md b/_sips/sips/2016-01-11-static-members.md index 23b0d3e4e9..22006c99c7 100644 --- a/_sips/sips/2016-01-11-static-members.md +++ b/_sips/sips/2016-01-11-static-members.md @@ -106,7 +106,7 @@ The following rules ensure that methods can be correctly compiled into static me 1. Only objects can have members annotated with `@static` -2. The fields annotated with `@static` should preceed any non-`@static` fields. This ensures that we do not introduce surprises for users in initialization order of this class. +2. The fields annotated with `@static` should precede any non-`@static` fields. This ensures that we do not introduce surprises for users in initialization order of this class. 3. The right hand side of a method or field annotated with `@static` can only refer to top-level classes, members of globally accessible objects and `@static` members. In particular, for non-static objects `this` is not accesible. `super` is never accessible. @@ -205,12 +205,12 @@ Let's consider possible options: - if the field `c` is emitted as `static` on the bytecode level, it will be initialized before the `c` in superclass is initialized, reordering side-effects in initializers; - if the field `c` is _not_ emitted as `static` but the field `d` is, then the order of initialization would also be affected, reordering side-effects. -Based on the previous study done in preparation for this SIP, the authors believe that the only reasonable way to maintain current sematics would be to say that such alternative would require these rules: +Based on the previous study done in preparation for this SIP, the authors believe that the only reasonable way to maintain current semantics would be to say that such alternative would require these rules: - only the fields which were not declared by parents of the object can be emitted as static; - only fields that are lexically defined before any non-static field or statement in the body can be emitted as static. -Authors believe that the alternative would require the same effort to implement, but will be less intuitive to users and harder to control as, for example, reodering fields in object might not be binary compatible. +Authors believe that the alternative would require the same effort to implement, but will be less intuitive to users and harder to control as, for example, reordering fields in object might not be binary compatible. ## See Also ## * [SI-4581](https://issues.scala-lang.org/browse/SI-4581) is a request for a `@static` annotation diff --git a/_sips/sips/2016-07-25-unsigned-integers.md b/_sips/sips/2016-07-25-unsigned-integers.md index 1a0428c246..8d2d8a5484 100644 --- a/_sips/sips/2016-07-25-unsigned-integers.md +++ b/_sips/sips/2016-07-25-unsigned-integers.md @@ -468,7 +468,7 @@ arithmetic expressions for all number types (both primitive signed ones and user-defined unsigned ones.) For each type we've generated 4 benchmarks that use `+, -, *` ops (fastops) -and 4 benchmarks that use `+, -, *, /, %` (allops). Each of the 4 benchmarks uses exatly +and 4 benchmarks that use `+, -, *, /, %` (allops). Each of the 4 benchmarks uses exactly the same arithmetic expressions for all types. Benchmarks on bytes and shorts wrap back to corresponding type after each operation. diff --git a/_sips/sips/2016-09-09-inline-meta.md b/_sips/sips/2016-09-09-inline-meta.md index 1ef66a2fdb..cd121f6389 100644 --- a/_sips/sips/2016-09-09-inline-meta.md +++ b/_sips/sips/2016-09-09-inline-meta.md @@ -408,7 +408,7 @@ do these desugarings, and scala.meta shields us from this fact. We can use the WYSIWYG pattern `q"$_($prefix)"` in order to unwrap the original prefix of the call. Moreover, we don't have to worry about the compiler internally mangling non-alphanumeric names. -Again, even if the underying macro engine internally does name mangling, scala.meta abstracts away such implementation details. +Again, even if the underlying macro engine internally does name mangling, scala.meta abstracts away such implementation details. Finally, we are able to improve on scala.reflect thanks to more precise quasiquotes. If in the current macro system, we used `q"($name: $_) => ..."` to match the `fn` argument, diff --git a/_sips/sips/2017-01-13-binary-compatibility.md b/_sips/sips/2017-01-13-binary-compatibility.md index 90720c1beb..cc3837b2b0 100644 --- a/_sips/sips/2017-01-13-binary-compatibility.md +++ b/_sips/sips/2017-01-13-binary-compatibility.md @@ -161,7 +161,7 @@ class FeaturesInBodies { ## Features that will fail compilation with `@stableABI` The features listed below have complex encodings that may change in future versions. We prefer not to compromise on them. -Most of those features can be simulated in a binary compatible way by writing a verbose re-implemtation +Most of those features can be simulated in a binary compatible way by writing a verbose re-implementation which won't rely on desugaring performed inside compiler. Note that while those features are prohibited in the public API, they can be safely used inside bodies of the methods. @@ -237,7 +237,7 @@ across major versions, while MiMa checks that previously published artifacts ind so introduction of new members won't be prohibited. This is a use-case for MiMa. MiMa does not indicate how hard, if possible, would it be to maintain compatibility of a class across future versions of Scala. -Multiple features of Scala, most notably lazy vals and traits, have been compiled diffently by different Scala versions +Multiple features of Scala, most notably lazy vals and traits, have been compiled differently by different Scala versions making porting existing compiled bytecode across versions very hard. MiMa will complain retroactively that the new version is incompatible with the old one. `@stableABI` will instead indicate at compile time that the old version used features whose encoding is prone to change. diff --git a/_sips/sips/2017-09-20-opaque-types.md b/_sips/sips/2017-09-20-opaque-types.md index 76c786dfe3..903750bb23 100644 --- a/_sips/sips/2017-09-20-opaque-types.md +++ b/_sips/sips/2017-09-20-opaque-types.md @@ -498,7 +498,7 @@ package object fixed { This is an interesting example which is intended to show that opaque types (unlike type aliases) have an independent existence, even within -the companion. This means that unlike type alises, `Fix[F]` should not +the companion. This means that unlike type aliases, `Fix[F]` should not result in an infinite expansion in the above code. The `Fix` type is useful to implementing recursion schemes, or just @@ -663,7 +663,7 @@ package object groups { The example demonstrates using an abstract class (`Wrapper`) to share code between opaque type companion objects. Like the tagging example, we can use two methods (`wraps` and `unwraps`) to wrap and unwrap `A` -types, even if neseted in an arbitrary context (`G[_]`). These methods +types, even if nested in an arbitrary context (`G[_]`). These methods cannot be implemented in `Wrapper` because each opaque type companion contains the only scope where its particular methods can be implemented. @@ -747,7 +747,7 @@ There are several key ideas in the current, work-in-progress implementation: * To meet the type equivalence relationship for opaque types, we synthesize two implicit conversions inside the opaque type companion, if they do not already exist. If `opaque type t = T`, then two implicit conversions are synthesized, one from `t` to `T` is synthesized and another for the - other way around. The body of these methods will use `t.asInstanceOf[T]` and viceversa **. + other way around. The body of these methods will use `t.asInstanceOf[T]` and vice versa **. * Phases after typer always dealias opaque types. This way, erasure and codegen can unwrap opaque types out of the box and, at the bytecode level, their underlying representation is used instead.