postponed addition of attribute {.scala}

michelou · michelou · commit d96b2a2a5567 · 2021-01-01T13:35:34.000+01:00
diff --git a/docs/docs/reference/changed-features/main-functions.md b/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:
diff --git a/docs/docs/reference/changed-features/match-syntax.md b/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
 
diff --git a/docs/docs/reference/changed-features/numeric-literals.md b/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:
 
diff --git a/docs/docs/reference/changed-features/operators.md b/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]
diff --git a/docs/docs/reference/changed-features/structural-types.md b/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.
diff --git a/docs/docs/reference/contextual/context-bounds.md b/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
diff --git a/docs/docs/reference/contextual/derivation.md b/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
diff --git a/docs/docs/reference/contextual/type-classes.md b/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.
 
diff --git a/docs/docs/reference/enums/adts.md b/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
diff --git a/docs/docs/reference/enums/desugarEnums.md b/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.
diff --git a/docs/docs/reference/enums/enums.md b/docs/docs/reference/enums/enums.md
@@ -110,7 +110,7 @@ For a more in-depth example of using Scala 3 enums from Java, see [this test](ht
 
 ### Implementation
 
-Enums are represented as `sealed`{.scala} classes that extend the `scala.reflect.Enum` trait.
+Enums are represented as `sealed` classes that extend the `scala.reflect.Enum` trait.
 This trait defines a single public method, `ordinal`:
 
 ```scala
@@ -123,7 +123,7 @@ transparent trait Enum extends Any, Product, Serializable:
    def ordinal: Int
 ```
 
-Enum values with `extends`{.scala} clauses get expanded to anonymous class instances.
+Enum values with `extends` clauses get expanded to anonymous class instances.
 For instance, the `Venus` value above would be defined like this:
 
 ```scala
@@ -133,7 +133,7 @@ val Venus: Planet = new Planet(4.869E24, 6051800.0):
    override def toString: String = "Venus"
 ```
 
-Enum values without `extends`{.scala} clauses all share a single implementation
+Enum values without `extends` clauses all share a single implementation
 that can be instantiated using a private method that takes a tag and a name as arguments.
 For instance, the first
 definition of value `Color.Red` above would expand to:
diff --git a/docs/docs/reference/metaprogramming/erased-terms-spec.md b/docs/docs/reference/metaprogramming/erased-terms-spec.md
@@ -5,10 +5,10 @@ title: "Erased Terms Spec"
 
 ## Rules
 
-1. The `erased`{.scala} modifier can appear:
+1. The `erased` modifier can appear:
    * At the start of a parameter block of a method, function or class
    * In a method definition
-   * In a `val`{.scala} definition (but not `lazy val`{.scala} or `var`{.scala})
+   * In a `val` definition (but not `lazy val` or `var`)
 
     ```scala
     erased val x = ...
@@ -23,39 +23,39 @@ title: "Erased Terms Spec"
     ```
 
 
-2. A reference to an `erased`{.scala} definition can only be used
-   * Inside the expression of argument to an `erased`{.scala} parameter
-   * Inside the body of an `erased`{.scala} `val`{.scala} or `def`{.scala}
+2. A reference to an `erased` definition can only be used
+   * Inside the expression of argument to an `erased` parameter
+   * Inside the body of an `erased` `val` or `def`
 
 
 3. Functions
-   * `(erased x1: T1, x2: T2, ..., xN: TN) => y : (erased T1, T2, ..., TN) => R`{.scala}
-   * `(given erased x1: T1, x2: T2, ..., xN: TN) => y: (given erased T1, T2, ..., TN) => R`{.scala}
-   * `(given erased T1) => R  <:<  erased T1 => R`{.scala}
-   * `(given erased T1, T2) => R  <:< (erased T1, T2) => R`{.scala}
+   * `(erased x1: T1, x2: T2, ..., xN: TN) => y : (erased T1, T2, ..., TN) => R`
+   * `(given erased x1: T1, x2: T2, ..., xN: TN) => y: (given erased T1, T2, ..., TN) => R`
+   * `(given erased T1) => R  <:<  erased T1 => R`
+   * `(given erased T1, T2) => R  <:< (erased T1, T2) => R`
    *  ...
 
-   Note that there is no subtype relation between `(erased T) => R`{.scala} and `T => R` (or `(given erased T) => R`{.scala} and `(given T) => R`{.scala})
+   Note that there is no subtype relation between `(erased T) => R` and `T => R` (or `(given erased T) => R` and `(given T) => R`)
 
 
 4. Eta expansion
 
-   if `def f(erased x: T): U`{.scala} then `f: (erased T) => U`{.scala}.
+   if `def f(erased x: T): U` then `f: (erased T) => U`.
 
 
 5. Erasure Semantics
-   * All `erased`{.scala} parameters are removed from the function
-   * All argument to `erased`{.scala} parameters are not passed to the function
-   * All `erased`{.scala} definitions are removed
-   * All `(erased T1, T2, ..., TN) => R`{.scala} and `(given erased T1, T2, ..., TN) => R`{.scala} become `() => R`{.scala}
+   * All `erased` parameters are removed from the function
+   * All argument to `erased` parameters are not passed to the function
+   * All `erased` definitions are removed
+   * All `(erased T1, T2, ..., TN) => R` and `(given erased T1, T2, ..., TN) => R` become `() => R`
 
 
 6. Overloading
 
-   Method with `erased`{.scala} parameters will follow the normal overloading constraints after erasure.
+   Method with `erased` parameters will follow the normal overloading constraints after erasure.
 
 
 7. Overriding
-   * Member definitions overriding each other must both be `erased`{.scala} or not be `erased`{.scala}
-   * `def foo(x: T): U`{.scala} cannot be overridden by `def foo(erased x: T): U`{.scala} and vice-versa
+   * Member definitions overriding each other must both be `erased` or not be `erased`
+   * `def foo(x: T): U` cannot be overridden by `def foo(erased x: T): U` and vice-versa
 
diff --git a/docs/docs/reference/metaprogramming/erased-terms.md b/docs/docs/reference/metaprogramming/erased-terms.md
@@ -65,8 +65,8 @@ def methodWithErasedInt2(erased i: Int): Int =
    methodWithErasedInt1(i) // OK
 ```
 
-Not only parameters can be marked as erased, `val`{.scala} and `def`{.scala} can also be marked
-with `erased`{.scala}. These will also only be usable as arguments to `erased`{.scala}
+Not only parameters can be marked as erased, `val` and `def` can also be marked
+with `erased`. These will also only be usable as arguments to `erased`
 parameters.
 
 ```scala
@@ -153,7 +153,7 @@ object Machine:
 ```
 
 Note that in [Inline](./inline.md) we discussed `erasedValue` and inline
-matches. `erasedValue` is implemented with `erased`{.scala}, so the state machine above
+matches. `erasedValue` is implemented with `erased`, so the state machine above
 can be encoded as follows:
 
 ```scala
diff --git a/docs/docs/reference/new-types/polymorphic-function-types.md b/docs/docs/reference/new-types/polymorphic-function-types.md
diff --git a/docs/docs/reference/new-types/union-types-spec.md b/docs/docs/reference/new-types/union-types-spec.md
