diff --git a/docs/docs/reference/changed-features/compiler-plugins.md b/docs/docs/reference/changed-features/compiler-plugins.md index 0d76ba186a96..9d86a485b9ab 100644 --- a/docs/docs/reference/changed-features/compiler-plugins.md +++ b/docs/docs/reference/changed-features/compiler-plugins.md @@ -3,7 +3,7 @@ layout: doc-page title: "Changes in Compiler Plugins" --- -Compiler plugins are supported by Dotty since 0.9. There are two notable changes +Compiler plugins are supported by Dotty (and Scala 3) since 0.9. There are two notable changes compared to `scalac`: - No support for analyzer plugins @@ -13,14 +13,14 @@ compared to `scalac`: normal type checking. This is a very powerful feature but for production usages, a predictable and consistent type checker is more important. -For experimentation and research, Dotty introduces _research plugin_. Research plugins +For experimentation and research, Scala 3 introduces _research plugin_. Research plugins are more powerful than `scalac` analyzer plugins as they let plugin authors customize the whole compiler pipeline. One can easily replace the standard typer by a custom one or create a parser for a domain-specific language. However, research plugins are only -enabled for nightly or snaphot releases of Dotty. +enabled for nightly or snaphot releases of Scala 3. Common plugins that add new phases to the compiler pipeline are called -_standard plugins_ in Dotty. In terms of features, they are similar to +_standard plugins_ in Scala 3. In terms of features, they are similar to `scalac` plugins, despite minor changes in the API. ## Using Compiler Plugins @@ -41,7 +41,7 @@ pluginClass=dividezero.DivideZero This is different from `scalac` plugins that required a `scalac-plugin.xml` file. -Starting from 1.1.5, `sbt` also supports Dotty compiler plugins. Please refer to the +Starting from 1.1.5, `sbt` also supports Scala 3 compiler plugins. Please refer to the `sbt` [documentation][2] for more information. ## Writing a Standard Compiler Plugin diff --git a/docs/docs/reference/changed-features/eta-expansion.md b/docs/docs/reference/changed-features/eta-expansion.md index 365a0e2d09a7..074134536146 100644 --- a/docs/docs/reference/changed-features/eta-expansion.md +++ b/docs/docs/reference/changed-features/eta-expansion.md @@ -35,8 +35,7 @@ rather than `next _`. The reason for excluding nullary methods from automatic eta expansion is that Scala implicitly inserts the `()` argument, which would conflict with eta expansion. Automatic `()` insertion is -[limited](../dropped-features/auto-apply.md) in Dotty, but the fundamental ambiguity +[limited](../dropped-features/auto-apply.md) in Scala 3, but the fundamental ambiguity remains. [More details](eta-expansion-spec.md) - diff --git a/docs/docs/reference/changed-features/implicit-conversions-spec.md b/docs/docs/reference/changed-features/implicit-conversions-spec.md index 9a1b52d6bbd2..0c6a90444150 100644 --- a/docs/docs/reference/changed-features/implicit-conversions-spec.md +++ b/docs/docs/reference/changed-features/implicit-conversions-spec.md @@ -94,8 +94,8 @@ language: ```scala implicit val m: Map[Int, String] = Map(1 -> "abc") -val x: String = 1 // scalac: assigns "abc" to x - // Dotty: type error +val x: String = 1 // Scala 2: assigns "abc" to x + // Scala 3: type error ``` This snippet contains a type error. The right hand side of `val x` @@ -119,4 +119,3 @@ For more information about implicit resolution, see [Changes in Implicit Resolution](implicit-resolution.md). Other details are available in [PR #2065](https://github.com/lampepfl/dotty/pull/2065) - diff --git a/docs/docs/reference/changed-features/implicit-resolution.md b/docs/docs/reference/changed-features/implicit-resolution.md index 6f848c040d0d..911a3a2697c2 100644 --- a/docs/docs/reference/changed-features/implicit-resolution.md +++ b/docs/docs/reference/changed-features/implicit-resolution.md @@ -2,7 +2,7 @@ layout: doc-page title: "Changes in Implicit Resolution" --- -This page describes changes to the implicit resolution that apply both to the new `given`s and to the old-style `implicit`s in Dotty. +This page describes changes to the implicit resolution that apply both to the new `given`s and to the old-style `implicit`s in Scala 3. Implicit resolution uses a new algorithm which caches implicit results more aggressively for performance. There are also some changes that affect implicits on the language level. @@ -114,7 +114,7 @@ the implicit search for `Q` fails. **5.** The treatment of divergence errors has also changed. A divergent implicit is treated as a normal failure, after which alternatives are still tried. This also makes sense: Encountering a divergent implicit means that we assume that no finite solution can be found on the corresponding path, but another path can still be tried. By contrast, most (but not all) divergence errors in Scala 2 would terminate the implicit search as a whole. -**6.** Scala-2 gives a lower level of priority to implicit conversions with call-by-name parameters relative to implicit conversions with call-by-value parameters. Dotty drops this distinction. So the following code snippet would be ambiguous in Dotty: +**6.** Scala-2 gives a lower level of priority to implicit conversions with call-by-name parameters relative to implicit conversions with call-by-value parameters. Scala 3 drops this distinction. So the following code snippet would be ambiguous in Scala 3: ```scala implicit def conv1(x: Int): A = new A(x) diff --git a/docs/docs/reference/changed-features/interpolation-escapes.md b/docs/docs/reference/changed-features/interpolation-escapes.md index aafeaacf15c2..75450b6f1d82 100644 --- a/docs/docs/reference/changed-features/interpolation-escapes.md +++ b/docs/docs/reference/changed-features/interpolation-escapes.md @@ -5,7 +5,7 @@ title: Escapes in interpolations In Scala 2 there was no straightforward way to represent a single quote character `"` in a single quoted interpolation. A `\` character can't be used for that because interpolators themselves decide how to handle escaping, so the parser doesn't know whether the `"` should be escaped or used as a terminator. -In Dotty, you can use the `$` meta character of interpolations to escape a `"` character. +In Scala 3, you can use the `$` meta character of interpolations to escape a `"` character. ```scala val inventor = "Thomas Edison" diff --git a/docs/docs/reference/changed-features/lazy-vals-init.md b/docs/docs/reference/changed-features/lazy-vals-init.md index b137b84d80db..5fbb126e5ddf 100644 --- a/docs/docs/reference/changed-features/lazy-vals-init.md +++ b/docs/docs/reference/changed-features/lazy-vals-init.md @@ -3,7 +3,7 @@ layout: doc-page title: Lazy Vals initialization --- -Dotty implements [Version 6](https://docs.scala-lang.org/sips/improved-lazy-val-initialization.html#version-6---no-synchronization-on-this-and-concurrent-initialization-of-fields) +Scala 3 implements [Version 6](https://docs.scala-lang.org/sips/improved-lazy-val-initialization.html#version-6---no-synchronization-on-this-and-concurrent-initialization-of-fields) of the [SIP-20] improved lazy vals initialization proposal. ## Motivation @@ -23,7 +23,7 @@ class Foo { } ``` -The Dotty compiler will generate code equivalent to: +The Scala 3 compiler will generate code equivalent to: ```scala class Foo { diff --git a/docs/docs/reference/changed-features/overload-resolution.md b/docs/docs/reference/changed-features/overload-resolution.md index aa7e4fdea0c7..81fd9b8b786c 100644 --- a/docs/docs/reference/changed-features/overload-resolution.md +++ b/docs/docs/reference/changed-features/overload-resolution.md @@ -3,7 +3,7 @@ layout: doc-page title: "Changes in Overload Resolution" --- -Overload resolution in Dotty improves on Scala 2 in two ways. +Overload resolution in Scala 3 improves on Scala 2 in two ways. First, it takes all argument lists into account instead of just the first argument list. Second, it can infer parameter types of function values even if they @@ -49,7 +49,7 @@ overload resolution based on additional argument blocks. The handling of function values with missing parameter types has been improved. We can now pass such values in the first argument list of an overloaded application, provided that the remaining parameters suffice for picking a variant of the overloaded function. -For example, the following code compiles in Dotty, while it results in an +For example, the following code compiles in Scala 3, while it results in an missing parameter type error in Scala2: ```scala def f(x: Int, f2: Int => Int) = f2(x) diff --git a/docs/docs/reference/changed-features/pattern-matching.md b/docs/docs/reference/changed-features/pattern-matching.md index 3b4a88b90c3c..cb389db5f3b3 100644 --- a/docs/docs/reference/changed-features/pattern-matching.md +++ b/docs/docs/reference/changed-features/pattern-matching.md @@ -3,9 +3,9 @@ layout: doc-page title: "Option-less pattern matching" --- -Dotty implementation of pattern matching was greatly simplified compared to Scala 2. From a user perspective, this means that Scala 3 generated patterns are a *lot* easier to debug, as variables all show up in debug modes and positions are correctly preserved. +The implementation of pattern matching in Scala 3 was greatly simplified compared to Scala 2. From a user perspective, this means that Scala 3 generated patterns are a *lot* easier to debug, as variables all show up in debug modes and positions are correctly preserved. -Dotty supports a superset of Scala 2 [extractors](https://www.scala-lang.org/files/archive/spec/2.13/08-pattern-matching.html#extractor-patterns). +Scala 3 supports a superset of Scala 2 [extractors](https://www.scala-lang.org/files/archive/spec/2.13/08-pattern-matching.html#extractor-patterns). ## Extractors diff --git a/docs/docs/reference/contextual/derivation.md b/docs/docs/reference/contextual/derivation.md index 892c0a273f57..3d2ec69ee6a8 100644 --- a/docs/docs/reference/contextual/derivation.md +++ b/docs/docs/reference/contextual/derivation.md @@ -122,12 +122,12 @@ Mirror.Product { Note the following properties of `Mirror` types, + Properties are encoded using types rather than terms. This means that they have no runtime footprint unless used and - also that they are a compile time feature for use with Dotty's metaprogramming facilities. + also that they are a compile time feature for use with Scala 3's metaprogramming facilities. + The kinds of `MirroredType` and `MirroredElemTypes` match the kind of the data type the mirror is an instance for. This allows `Mirrors` to support ADTs of all kinds. + There is no distinct representation type for sums or products (ie. there is no `HList` or `Coproduct` type as in Scala 2 versions of shapeless). Instead the collection of child types of a data type is represented by an ordinary, - possibly parameterized, tuple type. Dotty's metaprogramming facilities can be used to work with these tuple types + possibly parameterized, tuple type. Scala 3's metaprogramming facilities can be used to work with these tuple types as-is, and higher level libraries can be built on top of them. + For both product and sum types, the elements of `MirroredElemTypes` are arranged in definition order (i.e. `Branch[T]` precedes `Leaf[T]` in `MirroredElemTypes` for `Tree` because `Branch` is defined before `Leaf` in the source file). @@ -152,12 +152,12 @@ provider of an ADT with a `derives` clause has to know about the derivation of a Note that `derived` methods may have context `Mirror` parameters indirectly (e.g. by having a context argument which in turn has a context `Mirror` parameter, or not at all (e.g. they might use some completely different user-provided mechanism, for -instance using Dotty macros or runtime reflection). We expect that (direct or indirect) `Mirror` based implementations +instance using Scala 3 macros or runtime reflection). We expect that (direct or indirect) `Mirror` based implementations will be the most common and that is what this document emphasises. Type class authors will most likely use higher level derivation or generic programming libraries to implement `derived` methods. An example of how a `derived` method might be implemented using _only_ the low level facilities -described above and Dotty's general metaprogramming features is provided below. It is not anticipated that type class +described above and Scala 3's general metaprogramming features is provided below. It is not anticipated that type class authors would normally implement a `derived` method in this way, however this walkthrough can be taken as a guide for authors of the higher level derivation libraries that we expect typical type class authors will use (for a fully worked out example of such a library, see [shapeless 3](https://github.com/milessabin/shapeless/tree/shapeless-3)). @@ -165,7 +165,7 @@ worked out example of such a library, see [shapeless 3](https://github.com/miles #### How to write a type class `derived` method using low level mechanisms The low-level method we will use to implement a type class `derived` method in this example exploits three new -type-level constructs in Dotty: inline methods, inline matches, and implicit searches via `summonInline` or `summonFrom`. Given this definition of the +type-level constructs in Scala 3: inline methods, inline matches, and implicit searches via `summonInline` or `summonFrom`. Given this definition of the `Eq` type class, @@ -194,7 +194,7 @@ call sites (for instance the compiler generated instance definitions in the comp The body of this method (1) first materializes the `Eq` instances for all the child types of type the instance is being derived for. This is either all the branches of a sum type or all the fields of a product type. The -implementation of `summonAll` is `inline` and uses Dotty's `summonInline` construct to collect the instances as a +implementation of `summonAll` is `inline` and uses Scala 3's `summonInline` construct to collect the instances as a `List`, ```scala @@ -319,7 +319,7 @@ given derived$Eq[T](using eqT: Eq[T]): Eq[Opt[T]] = ``` Alternative approaches can be taken to the way that `derived` methods can be defined. For example, more aggressively -inlined variants using Dotty macros, whilst being more involved for type class authors to write than the example +inlined variants using Scala 3 macros, whilst being more involved for type class authors to write than the example above, can produce code for type classes like `Eq` which eliminate all the abstraction artefacts (eg. the `Lists` of child instances in the above) and generate code which is indistinguishable from what a programmer might write by hand. As a third example, using a higher level library such as shapeless the type class author could define an equivalent @@ -402,8 +402,8 @@ lockstep and it has to assert this conformance in some places using casts. If ge written these casts will never fail. As mentioned, however, the compiler-provided mechanism is intentionally very low level and it is anticipated that -higher level type class derivation and generic programming libraries will build on this and Dotty's other +higher level type class derivation and generic programming libraries will build on this and Scala 3's other metaprogramming facilities to hide these low-level details from type class authors and general users. Type class derivation in the style of both shapeless and Magnolia are possible (a prototype of shapeless 3, which combines aspects of both shapeless 2 and Magnolia has been developed alongside this language feature) as is a more aggressively -inlined style, supported by Dotty's new quote/splice macro and inlining facilities. +inlined style, supported by Scala 3's new quote/splice macro and inlining facilities. diff --git a/docs/docs/reference/contextual/motivation.md b/docs/docs/reference/contextual/motivation.md index a0bd53e03919..ecaf2bedd361 100644 --- a/docs/docs/reference/contextual/motivation.md +++ b/docs/docs/reference/contextual/motivation.md @@ -35,7 +35,7 @@ Particular criticisms are: ``` one cannot write `currentMap("abc")` since the string "abc" is taken as explicit argument to the implicit `ctx` parameter. One has to write `currentMap.apply("abc")` instead, which is awkward and irregular. For the same reason, a method definition can only have one implicit parameter section and it must always come last. This restriction not only reduces orthogonality, but also prevents some useful program constructs, such as a method with a regular parameter whose type depends on an implicit value. Finally, it's also a bit annoying that implicit parameters must have a name, even though in many cases that name is never referenced. - 5. Implicits pose challenges for tooling. The set of available implicits depends on context, so command completion has to take context into account. This is feasible in an IDE but docs like ScalaDoc that are based static web pages can only provide an approximation. Another problem is that failed implicit searches often give very unspecific error messages, in particular if some deeply recursive implicit search has failed. Note that the Dotty compiler has already made a lot of progress in the error diagnostics area. If a recursive search fails some levels down, it shows what was constructed and what is missing. Also, it suggests imports that can bring missing implicits in scope. + 5. Implicits pose challenges for tooling. The set of available implicits depends on context, so command completion has to take context into account. This is feasible in an IDE but docs like ScalaDoc that are based static web pages can only provide an approximation. Another problem is that failed implicit searches often give very unspecific error messages, in particular if some deeply recursive implicit search has failed. Note that the Scala 3 compiler has already made a lot of progress in the error diagnostics area. If a recursive search fails some levels down, it shows what was constructed and what is missing. Also, it suggests imports that can bring missing implicits in scope. None of the shortcomings is fatal, after all implicits are very widely used, and many libraries and applications rely on them. But together, they make code using implicits a lot more cumbersome and less clear than it could be. @@ -78,4 +78,3 @@ Could we achieve the same goals by tweaking existing implicits? After having tri - Third, even if we would somehow succeed with migration, we still have the problem how to teach this. We cannot make existing tutorials go away. Almost all existing tutorials start with implicit conversions, which will go away; they use normal imports, which will go away, and they explain calls to methods with implicit parameters by expanding them to plain applications, which will also go away. This means that we'd have to add modifications and qualifications to all existing literature and courseware, likely causing more confusion with beginners instead of less. By contrast, with a new syntax there is a clear criterion: Any book or courseware that mentions `implicit` is outdated and should be updated. - diff --git a/docs/docs/reference/contextual/relationship-implicits.md b/docs/docs/reference/contextual/relationship-implicits.md index a671418b9299..dced9015adf4 100644 --- a/docs/docs/reference/contextual/relationship-implicits.md +++ b/docs/docs/reference/contextual/relationship-implicits.md @@ -103,7 +103,7 @@ asked for. Context bounds are the same in both language versions. They expand to the respective forms of implicit parameters. -**Note:** To ease migration, context bounds in Dotty map for a limited time to old-style implicit parameters for which arguments can be passed either in a using clause or +**Note:** To ease migration, context bounds in Scala 3 map for a limited time to old-style implicit parameters for which arguments can be passed either in a using clause or in a normal argument list. Once old-style implicits are deprecated, context bounds will map to using clauses instead. @@ -141,7 +141,7 @@ Implicit by-name parameters are not supported in Scala 2, but can be emulated to ### Implicit Conversions -Implicit conversion methods in Scala 2 can be expressed as given instances of the `scala.Conversion` class in Dotty. E.g. instead of +Implicit conversion methods in Scala 2 can be expressed as given instances of the `scala.Conversion` class in Scala 3. E.g. instead of ```scala implicit def stringToToken(str: String): Token = new Keyword(str) @@ -162,18 +162,18 @@ given stringToToken: Conversion[String, Token] = KeyWord(_) ### Implicit Classes -Implicit classes in Scala 2 are often used to define extension methods, which are directly supported in Dotty. Other uses of implicit classes can be simulated by a pair of a regular class and a given `Conversion` instance. +Implicit classes in Scala 2 are often used to define extension methods, which are directly supported in Scala 3. Other uses of implicit classes can be simulated by a pair of a regular class and a given `Conversion` instance. ### Implicit Values -Implicit `val` definitions in Scala 2 can be expressed in Dotty using a regular `val` definition and an alias given. +Implicit `val` definitions in Scala 2 can be expressed in Scala 3 using a regular `val` definition and an alias given. E.g., Scala 2's ```scala lazy implicit val pos: Position = tree.sourcePos ``` -can be expressed in Dotty as +can be expressed in Scala 3 as ```scala lazy val pos: Position = tree.sourcePos @@ -182,13 +182,13 @@ given Position = pos ### Abstract Implicits -An abstract implicit `val` or `def` in Scala 2 can be expressed in Dotty using a regular abstract definition and an alias given. E.g., Scala 2's +An abstract implicit `val` or `def` in Scala 2 can be expressed in Scala 3 using a regular abstract definition and an alias given. E.g., Scala 2's ```scala implicit def symDecorator: SymDecorator ``` -can be expressed in Dotty as +can be expressed in Scala 3 as ```scala def symDecorator: SymDecorator @@ -197,7 +197,7 @@ given SymDecorator = symDecorator ## Implementation Status and Timeline -The Dotty implementation implements both Scala-2's implicits and the new abstractions. In fact, support for Scala-2's implicits is an essential part of the common language subset between 2.13/2.14 and Dotty. +The Scala 3 implementation implements both Scala-2's implicits and the new abstractions. In fact, support for Scala-2's implicits is an essential part of the common language subset between 2.13/2.14 and Scala 3. Migration to the new abstractions will be supported by making automatic rewritings available. Depending on adoption patterns, old style implicits might start to be deprecated in a version following Scala 3.0. diff --git a/docs/docs/reference/dropped-features/auto-apply.md b/docs/docs/reference/dropped-features/auto-apply.md index 29bed8a7fe20..db21008cd0a4 100644 --- a/docs/docs/reference/dropped-features/auto-apply.md +++ b/docs/docs/reference/dropped-features/auto-apply.md @@ -9,13 +9,13 @@ calling a nullary method without arguments. E.g. def next(): T = ... next // is expanded to next() ``` -In Dotty, this idiom is an error. +In Scala 3, this idiom is an error. ```scala next ^ missing arguments for method next ``` -In Dotty, the application syntax has to follow exactly the parameter +In Scala 3, the application syntax has to follow exactly the parameter syntax. Excluded from this rule are methods that are defined in Java or that override methods defined in Java. The reason for being more lenient with such methods is that otherwise everyone would have to @@ -36,11 +36,11 @@ methods without a `()` parameter list whereas side-effecting methods should be defined with it. Methods defined in Java cannot make this distinction; for them a `()` is always mandatory. So Scala fixes the problem on the client side, by allowing the parameterless references. -But where Scala allows that freedom for all method references, Dotty +But where Scala allows that freedom for all method references, Scala 3 restricts it to references of external methods that are not defined -themselves in Dotty. +themselves in Scala 3. -For reasons of backwards compatibility, Dotty for the moment also +For reasons of backwards compatibility, Scala 3 for the moment also auto-inserts `()` for nullary methods that are defined in Scala 2, or that override a method defined in Scala 2. It turns out that, because the correspondence between definition and call was not enforced in @@ -53,7 +53,7 @@ def toInt(): Int whereas `toInt` is written without parameters everywhere else. Enforcing strict parameter correspondence for references to such methods would project the inconsistencies to client code, which -is undesirable. So Dotty opts for more leniency when type-checking +is undesirable. So Scala 3 opts for more leniency when type-checking references to such methods until most core libraries in Scala 2 have been cleaned up. @@ -75,8 +75,8 @@ requirement. ### Migrating code Existing Scala code with inconsistent parameters can still be compiled -in Dotty under `-source 3.0-migration`. When paired with the `-rewrite` -option, the code will be automatically rewritten to conform to Dotty's +in Scala 3 under `-source 3.0-migration`. When paired with the `-rewrite` +option, the code will be automatically rewritten to conform to Scala 3's stricter checking. ### Reference diff --git a/docs/docs/reference/dropped-features/class-shadowing.md b/docs/docs/reference/dropped-features/class-shadowing.md index d9b4c6fd74d8..a733273fc0ed 100644 --- a/docs/docs/reference/dropped-features/class-shadowing.md +++ b/docs/docs/reference/dropped-features/class-shadowing.md @@ -3,7 +3,7 @@ layout: doc-page title: "Dropped: Class Shadowing" --- -Scala so far allowed patterns like this: +Scala 2 so far allowed patterns like this: ```scala class Base { class Ops { ... } @@ -13,15 +13,15 @@ class Sub extends Base { class Ops { ... } } ``` -Dotty rejects this with the error message: +Scala 3 rejects this with the error message: ```scala 6 | class Ops { } | ^ |class Ops cannot have the same name as class Ops in class Base -- class definitions cannot be overridden ``` The issue is that the two `Ops` classes _look_ like one overrides the -other, but classes in Scala cannot be overridden. To keep things clean -(and its internal operations consistent) the Dotty compiler forces you +other, but classes in Scala 2 cannot be overridden. To keep things clean +(and its internal operations consistent) the Scala 3 compiler forces you to rename the inner classes so that their names are different. [More details](./class-shadowing-spec.md) diff --git a/docs/docs/reference/dropped-features/early-initializers.md b/docs/docs/reference/dropped-features/early-initializers.md index a0b24fa36162..7b7179bf15cd 100644 --- a/docs/docs/reference/dropped-features/early-initializers.md +++ b/docs/docs/reference/dropped-features/early-initializers.md @@ -8,4 +8,4 @@ Early initializers of the form class C extends { ... } with SuperClass ... ``` have been dropped. They were rarely used, and mostly to compensate for the lack of -[trait parameters](../other-new-features/trait-parameters.md), which are now directly supported in Dotty. +[trait parameters](../other-new-features/trait-parameters.md), which are now directly supported in Scala 3. diff --git a/docs/docs/reference/dropped-features/existential-types.md b/docs/docs/reference/dropped-features/existential-types.md index 0fcc7a256d95..606a712a619b 100644 --- a/docs/docs/reference/dropped-features/existential-types.md +++ b/docs/docs/reference/dropped-features/existential-types.md @@ -6,7 +6,7 @@ title: "Dropped: Existential Types" Existential types using `forSome` have been dropped. The reasons for dropping them are: - Existential types violate a type soundness principle on which DOT - and Dotty are constructed. That principle says that every + and Scala 3 are constructed. That principle says that every prefix (`p`, respectvely `S`) of a type selection `p.T` or `S#T` must either come from a value constructed at runtime or refer to a type that is known to have only good bounds. @@ -27,6 +27,6 @@ is treated as the type `Map`, where the first type parameter is upper-bounded by `AnyRef` and the second type parameter is an alias of `Int`. -When reading classfiles compiled with _scalac_, Dotty will do a best +When reading classfiles compiled with _scalac_, Scala 3 will do a best effort to approximate existential types with its own types. It will issue a warning that a precise emulation is not possible. diff --git a/docs/docs/reference/dropped-features/macros.md b/docs/docs/reference/dropped-features/macros.md index 2742416e2c0a..aaf180ee7e84 100644 --- a/docs/docs/reference/dropped-features/macros.md +++ b/docs/docs/reference/dropped-features/macros.md @@ -5,11 +5,11 @@ title: "Dropped: Scala 2 Macros" The previous, experimental macro system has been dropped. -Instead, there is a cleaner, more restricted system based on two complementary concepts: `inline` and `'{ ... }`/`${ ... }` code generation. +Instead, there is a cleaner, more restricted system based on two complementary concepts: `inline` and `'{ ... }`/`${ ... }` code generation. `'{ ... }` delays the compilation of the code and produces an object containing the code, dually `${ ... }` evaluates an expression which produces code and inserts it in the surrounding `${ ... }`. In this setting, a definition marked as inlined containing a `${ ... }` is a macro, the code inside the `${ ... }` is executed at compile-time and produces code in the form of `'{ ... }`. Additionally, the contents of code can be inspected and created with a more complex reflection API (TASTy Reflect) as an extension of `'{ ... }`/`${ ... }` framework. -* `inline` has been [implemented](../metaprogramming/inline.md) in Dotty. -* Quotes `'{ ... }` and splices `${ ... }` has been [implemented](../metaprogramming/macros.md) in Dotty. +* `inline` has been [implemented](../metaprogramming/inline.md) in Scala 3. +* Quotes `'{ ... }` and splices `${ ... }` has been [implemented](../metaprogramming/macros.md) in Scala 3. * [TASTy reflect](../metaprogramming/tasty-reflect.md) provides more complex tree based APIs to inspect or create quoted code. diff --git a/docs/docs/reference/dropped-features/procedure-syntax.md b/docs/docs/reference/dropped-features/procedure-syntax.md index a345cd9e0eb9..7432069295a2 100644 --- a/docs/docs/reference/dropped-features/procedure-syntax.md +++ b/docs/docs/reference/dropped-features/procedure-syntax.md @@ -12,7 +12,7 @@ has been dropped. You need to write one of the following instead: def f() = { ... } def f(): Unit = { ... } ``` -Dotty will accept the old syntax under the `-source:3.0-migration` option. +Scala 3 will accept the old syntax under the `-source:3.0-migration` option. If the `-migration` option is set, it can even rewrite old syntax to new. The [ScalaFix](https://scalacenter.github.io/scalafix/) tool also -can rewrite procedure syntax to make it Dotty-compatible. +can rewrite procedure syntax to make it Scala-3-compatible. diff --git a/docs/docs/reference/dropped-features/type-projection.md b/docs/docs/reference/dropped-features/type-projection.md index 3e926151f672..73b7a358cb38 100644 --- a/docs/docs/reference/dropped-features/type-projection.md +++ b/docs/docs/reference/dropped-features/type-projection.md @@ -6,7 +6,7 @@ title: "Dropped: General Type Projection" Scala so far allowed general type projection `T#A` where `T` is an arbitrary type and `A` names a type member of `T`. -Dotty disallows this if `T` is an abstract type (class types and type aliases +Scala 3 disallows this if `T` is an abstract type (class types and type aliases are fine). This change was made because unrestricted type projection is [unsound](https://github.com/lampepfl/dotty/issues/1050). diff --git a/docs/docs/reference/dropped-features/weak-conformance-spec.md b/docs/docs/reference/dropped-features/weak-conformance-spec.md index 50dafcb5d946..9f442c9df80a 100644 --- a/docs/docs/reference/dropped-features/weak-conformance-spec.md +++ b/docs/docs/reference/dropped-features/weak-conformance-spec.md @@ -3,7 +3,7 @@ layout: doc-page title: Dropped: Weak Conformance - More Details --- -To simplify the underlying type theory, Dotty drops the notion of weak +To simplify the underlying type theory, Scala 3 drops the notion of weak conformance altogether. Instead, it provides more flexibility when assigning a type to a constant expression. The new rule is: diff --git a/docs/docs/reference/dropped-features/weak-conformance.md b/docs/docs/reference/dropped-features/weak-conformance.md index 2e64a2dcdf19..c925249db9e7 100644 --- a/docs/docs/reference/dropped-features/weak-conformance.md +++ b/docs/docs/reference/dropped-features/weak-conformance.md @@ -39,7 +39,7 @@ have an explicit type annotation embedded in their syntax (`f`, `d`, `.`, `L` or `'` for `Char`s) which ensures that their author really meant them to have that specific type). -Therefore, Dotty drops the general notion of weak conformance, and +Therefore, Scala 3 drops the general notion of weak conformance, and instead keeps one rule: `Int` literals are adapted to other numeric types if necessary. diff --git a/docs/docs/reference/metaprogramming/inline.md b/docs/docs/reference/metaprogramming/inline.md index 9812744169ab..915fdeb46b2d 100644 --- a/docs/docs/reference/metaprogramming/inline.md +++ b/docs/docs/reference/metaprogramming/inline.md @@ -35,7 +35,7 @@ This means that `logging` is treated as a _constant value_, equivalent to its right-hand side `false`. The right-hand side of such an `inline val` must itself be a [constant expression](https://scala-lang.org/files/archive/spec/2.13/06-expressions.html#constant-expressions). Used in this way, `inline` is equivalent to Java and Scala 2's `final`. Note that `final`, meaning -_inlined constant_, is still supported in Dotty, but will be phased out. +_inlined constant_, is still supported in Scala 3, but will be phased out. The `Logger` object contains a definition of the **inline method** `log`. This method will always be inlined at the point of call. @@ -193,10 +193,10 @@ option: Expansion is guaranteed instead of best effort, it happens in the frontend instead of in the backend, and it also applies to recursive methods. -To cross compile between both Dotty and Scalac, we introduce a new `@forceInline` +To cross compile between both Scala 3 and Scala 2, we introduce a new `@forceInline` annotation which is equivalent to the new `inline` modifier. Note that Scala 2 ignores the `@forceInline` annotation, so one must use both -annotations to guarantee inlining for Dotty and at the same time hint inlining +annotations to guarantee inlining for Scala 3 and at the same time hint inlining for Scala 2 (i.e. `@forceInline @inline`).