postponed addition of attribute {.scala}

Author: michelou

docs/docs/reference/changed-features/main-functions.md

@@ -4,7 +4,7 @@ title: "Main Methods"
 ---
 
 Scala 3 offers a new way to define programs that can be invoked from the command line:
-A `@main`{.scala} annotation on a method turns this method into an executable program.
+A `@main` annotation on a method turns this method into an executable program.
 Example:
 
 ```scala
@@ -30,13 +30,13 @@ This would generate a main program `happyBirthday` that could be called like thi
 Happy 23rd Birthday, Lisa and Peter!
 ```
 
-A `@main`{.scala} annotated method can be written either at the top-level or in a statically accessible object. The name of the program is in each case the name of the method, without any object prefixes. The `@main`{.scala} method can have an arbitrary number of parameters.
+A `@main` annotated method can be written either at the top-level or in a statically accessible object. The name of the program is in each case the name of the method, without any object prefixes. The `@main` method can have an arbitrary number of parameters.
 For each parameter type there must be an instance of the `scala.util.FromString` type class
 that is used to convert an argument string to the required parameter type.
 The parameter list of a main method can end in a repeated parameter that then
 takes all remaining arguments given on the command line.
 
-The program implemented from a `@main`{.scala} method checks that there are enough arguments on
+The program implemented from a `@main` method checks that there are enough arguments on
 the command line to fill in all parameters, and that argument strings are convertible to
 the required types. If a check fails, the program is terminated with an error message.
 
@@ -50,9 +50,9 @@ Illegal command line after first argument: more arguments expected
 Illegal command line: java.lang.NumberFormatException: For input string: "sixty"
 ```
 
-The Scala compiler generates a program from a `@main`{.scala} method `f` as follows:
+The Scala compiler generates a program from a `@main` method `f` as follows:
 
- - It creates a class named `f` in the package where the `@main`{.scala} method was found
+ - It creates a class named `f` in the package where the `@main` method was found
  - The class has a static method `main` with the usual signature. It takes an `Array[String]`
    as argument and returns `Unit`.
  - The generated `main` method calls method `f` with arguments converted using
@@ -76,7 +76,7 @@ final class happyBirthday:
 **Note**: The `<static>` modifier above expresses that the `main` method is generated
 as a static method of class `happyBirthDay`. It is not available for user programs in Scala. Regular "static" members are generated in Scala using objects instead.
 
-`@main`{.scala} methods are the recommended scheme to generate programs that can be invoked from the command line in Scala 3. They replace the previous scheme to write program as objects with a special `App` parent class. In Scala 2, `happyBirthday` could be written also like this:
+`@main` methods are the recommended scheme to generate programs that can be invoked from the command line in Scala 3. They replace the previous scheme to write program as objects with a special `App` parent class. In Scala 2, `happyBirthday` could be written also like this:
 
 ```scala
 object happyBirthday extends App:

docs/docs/reference/changed-features/match-syntax.md

@@ -4,9 +4,9 @@ title: "Match Expressions"
 ---
 
 The syntactical precedence of match expressions has been changed.
-`match`{.scala} is still a keyword, but it is used like an alphabetical operator. This has several consequences:
+`match` is still a keyword, but it is used like an alphabetical operator. This has several consequences:
 
-1. `match`{.scala} expressions can be chained:
+1. `match` expressions can be chained:
 
    ```scala
    xs match {
@@ -29,7 +29,7 @@ The syntactical precedence of match expressions has been changed.
       case "nonempty" => 1
    ```
 
-2. `match`{.scala} may follow a period:
+2. `match` may follow a period:
 
     ```scala
     if xs.match
@@ -41,7 +41,7 @@ The syntactical precedence of match expressions has been changed.
 
 3. The scrutinee of a match expression must be an `InfixExpr`. Previously the scrutinee could be
    followed by a type ascription `: T`, but this is no longer supported. So `x : T match { ... }`
-   now has to be written `(x: T) match { ... }`{.scala}.
+   now has to be written `(x: T) match { ... }`.
 
 ## Syntax
 

docs/docs/reference/changed-features/numeric-literals.md

@@ -66,7 +66,7 @@ gives a type error, since without an expected type `-10_000_000_000` is treated
 
 ### The FromDigits Trait
 
-To allow numeric literals, a type simply has to define a `given`{.scala} instance of the
+To allow numeric literals, a type simply has to define a `given` instance of the
 `scala.util.FromDigits` type class, or one of its subclasses. `FromDigits` is defined
 as follows:
 

docs/docs/reference/changed-features/operators.md

@@ -5,13 +5,13 @@ title: "Rules for Operators"
 
 The rules for infix operators have changed in some parts:
 
-First, an alphanumeric method can be used as an infix operator only if its definition carries an `infix`{.scala} modifier. Second, it is recommended (but not enforced) to
-augment definitions of symbolic operators with `@targetName`{.scala} annotations. Finally,
+First, an alphanumeric method can be used as an infix operator only if its definition carries an `infix` modifier. Second, it is recommended (but not enforced) to
+augment definitions of symbolic operators with `@targetName` annotations. Finally,
 a syntax change allows infix operators to be written on the left in a multi-line expression.
 
 ## The `infix` Modifier
 
-An `infix`{.scala} modifier on a method definition allows using the method as an infix operation. Example:
+An `infix` modifier on a method definition allows using the method as an infix operation. Example:
 
 ```scala
 import scala.annotation.targetName
@@ -54,7 +54,7 @@ any Unicode character `c` for which `java.lang.Character.isIdentifierPart(c)` re
 
 Infix operations involving symbolic operators are always allowed, so `infix` is redundant for methods with symbolic names.
 
-The `infix`{.scala} modifier can also be given to a type:
+The `infix` modifier can also be given to a type:
 
 ```scala
 infix type or[X, Y]

docs/docs/reference/changed-features/structural-types.md

@@ -144,7 +144,7 @@ val i3 = new Vehicle: // i3: Vehicle { val range: Int }
 i3.range
 ```
 
-The type of `i3` in this example is `Vehicle { val range: Int }`{.scala}. Hence,
+The type of `i3` in this example is `Vehicle { val range: Int }`. Hence,
 `i3.range` is well-formed. Since the base class `Vehicle` does not define a `range` field or method, we need structural dispatch to access the `range` field of the anonymous class that initializes `id3`. Structural dispatch
 is implemented by the base trait `reflect.Selectable` of `Vehicle`, which
 defines the necessary `selectDynamic` member.

docs/docs/reference/contextual/context-bounds.md

@@ -30,11 +30,11 @@ def g[T <: B : C](x: T): R = ...
 ## Migration
 
 To ease migration, context bounds in Dotty map in Scala 3.0 to old-style implicit parameters
-for which arguments can be passed either with a `(using ...)`{.scala} clause or with a normal application. From Scala 3.1 on, they will map to context parameters instead, as is described above.
+for which arguments can be passed either with a `(using ...)` clause or with a normal application. From Scala 3.1 on, they will map to context parameters instead, as is described above.
 
 If the source version is `3.1` and the `-migration` command-line option is set, any pairing of an evidence
 context parameter stemming from a context bound with a normal argument will give a migration
-warning. The warning indicates that a `(using ...)`{.scala} clause is needed instead. The rewrite can be
+warning. The warning indicates that a `(using ...)` clause is needed instead. The rewrite can be
 done automatically under `-rewrite`.
 
 ## Syntax

docs/docs/reference/contextual/derivation.md

@@ -353,7 +353,7 @@ ConstrApps        ::=  ConstrApp {‘with’ ConstrApp}
                     |  ConstrApp {‘,’ ConstrApp}
 ```
 
-Note: To align `extends`{.scala} clauses and `derives`{.scala} clauses, Scala 3 also allows multiple
+Note: To align `extends` clauses and `derives` clauses, Scala 3 also allows multiple
 extended types to be separated by commas. So the following is now legal:
 
 ```scala

docs/docs/reference/contextual/type-classes.md

@@ -8,7 +8,7 @@ A _type class_ is an abstract, parameterized type that lets you add new behavior
 * expressing how a type you don't own (from the standard or 3rd-party library) conforms to such behavior
 * expressing such a behavior for multiple types without involving sub-typing relationships (one `extends` another) between those types (see: [ad hoc polymorphism](https://en.wikipedia.org/wiki/Ad_hoc_polymorphism) for instance)
 
-Therefore in Scala 3, _type classes_ are just _traits_ with one or more parameters whose implementations are not defined through the `extends`{.scala} keyword, but by **given instances**.
+Therefore in Scala 3, _type classes_ are just _traits_ with one or more parameters whose implementations are not defined through the `extends` keyword, but by **given instances**.
 Here are some examples of common type classes:
 
 ### Semigroups and monoids
@@ -272,9 +272,9 @@ end readerMonad
 
 ### Summary
 
-The definition of a _type class_ is expressed with a parameterised type with abstract members, such as a `trait`{.scala}.
+The definition of a _type class_ is expressed with a parameterised type with abstract members, such as a `trait`.
 The main difference between subtype polymorphism and ad-hoc polymorphism with _type classes_ is how the definition of the _type class_ is implemented, in relation to the type it acts upon.
-In the case of a _type class_, its implementation for a concrete type is expressed through a `given`{.scala} instance definition, which is supplied as an implicit argument alongside the value it acts upon. With subtype polymorphism, the implementation is mixed into the parents of a class, and only a single term is required to perform a polymorphic operation. The type class solution
+In the case of a _type class_, its implementation for a concrete type is expressed through a `given` instance definition, which is supplied as an implicit argument alongside the value it acts upon. With subtype polymorphism, the implementation is mixed into the parents of a class, and only a single term is required to perform a polymorphic operation. The type class solution
 takes more effort to set up, but is more extensible: Adding a new interface to a
 class requires changing the source code of that class. But contrast, instances for type classes can be defined anywhere.
 

docs/docs/reference/enums/adts.md

@@ -19,7 +19,7 @@ parameterized with a value parameter `x`. It is a shorthand for writing a
 case class that extends `Option`. Since `None` is not parameterized, it
 is treated as a normal enum value.
 
-The `extends`{.scala} clauses that were omitted in the example above can also
+The `extends` clauses that were omitted in the example above can also
 be given explicitly:
 
 ```scala
@@ -30,12 +30,12 @@ enum Option[+T]:
 
 Note that the parent type of the `None` value is inferred as
 `Option[Nothing]`. Generally, all covariant type parameters of the enum
-class are minimized in a compiler-generated `extends`{.scala} clause whereas all
+class are minimized in a compiler-generated `extends` clause whereas all
 contravariant type parameters are maximized. If `Option` was non-variant,
 you would need to give the extends clause of `None` explicitly.
 
-As for normal enum values, the cases of an `enum`{.scala} are all defined in
-the `enum`{.scala}s companion object. So it's `Option.Some` and `Option.None`
+As for normal enum values, the cases of an `enum` are all defined in
+the `enum`s companion object. So it's `Option.Some` and `Option.None`
 unless the definitions are "pulled out" with an import:
 
 ```scala

docs/docs/reference/enums/desugarEnums.md

@@ -23,11 +23,11 @@ some terminology and notational conventions:
 
   Simple cases and value cases are collectively called _singleton cases_.
 
-The desugaring rules imply that class cases are mapped to case classes, and singleton cases are mapped to `val`{.scala} definitions.
+The desugaring rules imply that class cases are mapped to case classes, and singleton cases are mapped to `val` definitions.
 
 There are nine desugaring rules. Rule (1) desugars enum definitions. Rules
-(2) and (3) desugar simple cases. Rules (4) to (6) define `extends`{.scala} clauses for cases that
-are missing them. Rules (7) to (9) define how such cases with `extends`{.scala} clauses
+(2) and (3) desugar simple cases. Rules (4) to (6) define `extends` clauses for cases that
+are missing them. Rules (7) to (9) define how such cases with `extends` clauses
 map into `case class`es or `val`s.
 
 1. An `enum` definition
@@ -82,7 +82,7 @@ map into `case class`es or `val`s.
    ```
    where `Bi` is `Li` if `Vi = '+'` and `Ui` if `Vi = '-'`. This result is then further
    rewritten with rule (8). Simple cases of enums with non-variant type
-   parameters are not permitted (however value cases with explicit `extends`{.scala} clause are)
+   parameters are not permitted (however value cases with explicit `extends` clause are)
 
 5. A class case without an extends clause
    ```scala
@@ -191,7 +191,7 @@ The `ordinal` method is only generated if the enum does not extend from `java.la
 
 ### Scopes for Enum Cases
 
-A case in an `enum`{.scala} is treated similarly to a secondary constructor. It can access neither the enclosing `enum`{.scala} using `this`, nor its value parameters or instance members using simple
+A case in an `enum` is treated similarly to a secondary constructor. It can access neither the enclosing `enum` using `this`, nor its value parameters or instance members using simple
 identifiers.
 
 Even though translated enum cases are located in the enum's companion object, referencing
@@ -202,13 +202,13 @@ A Java-compatible enum is an enum that extends `java.lang.Enum`. The translation
 
 It is a compile-time error for a Java-compatible enum to have class cases.
 
-Cases such as `case C`{.scala} expand to a `@static val`{.scala} as opposed to a `val`{.scala}. This allows them to be generated as static fields of the enum type, thus ensuring they are represented the same way as Java enums.
+Cases such as `case C` expand to a `@static val` as opposed to a `val`. This allows them to be generated as static fields of the enum type, thus ensuring they are represented the same way as Java enums.
 
 ### Other Rules
 
  - A normal case class which is not produced from an enum case is not allowed to extend
 `scala.reflect.Enum`. This ensures that the only cases of an enum are the ones that are
 explicitly declared in it.
 
- - If an enum case has an `extends`{.scala} clause, the enum class must be one of the
+ - If an enum case has an `extends` clause, the enum class must be one of the
    classes that's extended.