Change snippet appearance. Add buttons and labels. UX improvements.

Author: pikinier20

docs/docs/reference/other-new-features/creator-applications.md

@@ -8,20 +8,20 @@ function application, without needing to write `new`.
 
 Scala 3 generalizes this scheme to all concrete classes. Example:
 
-```scala sc-id:1
+```scala sc-name:Base.scala
 class MyStringBuilder(s: String):
   def this() = this("")
 ```
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 MyStringBuilder("abc")  // old: new MyStringBuilder("abc")
 MyStringBuilder()       // old: new MyStringBuilder()
 ```
 
 This works since a companion object with two `apply` methods
 is generated together with the class. The object looks like this:
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 object MyStringBuilder:
   inline def apply(s: String): MyStringBuilder = new MyStringBuilder(s)
   inline def apply(): MyStringBuilder = new MyStringBuilder()

docs/docs/reference/other-new-features/explicit-nulls.md

@@ -147,13 +147,13 @@ We illustrate the rules with following examples:
 
   ==>
 
-  ```scala sc-id:1
+  ```scala sc-name:C.scala
   class C[T] { def foo(): T | Null = null }
   ```
 
   Notice this is rule is sometimes too conservative, as witnessed by
 
-  ```scala sc:fail sc-compile-with:1
+  ```scala sc:fail sc-compile-with:C.scala
   class InScala:
     val c: C[Boolean] = ???  // C as above
     val b: Boolean = c.foo() // no longer typechecks, since foo now returns Bool | Null
@@ -168,11 +168,11 @@ We illustrate the rules with following examples:
 
   ==>
 
-  ```scala sc-id:2
+  ```scala sc-name:Box.scala
   abstract class Box[T] { def get(): T | Null }
   ```
 
-  ```scala sc-compile-with:2
+  ```scala sc-compile-with:Box.scala
   abstract class BoxFactory[T] { def makeBox(): Box[T] | Null }
   ```
 
@@ -197,7 +197,7 @@ We illustrate the rules with following examples:
 
   ==>
 
-  ```scala sc-compile-with:2
+  ```scala sc-compile-with:Box.scala
   abstract class BoxFactory[T]:
     def makeBox(): Box[T | Null] | Null
     def makeCrazyBoxes(): java.util.List[Box[java.util.List[T] | Null]] | Null
@@ -250,7 +250,7 @@ We illustrate the rules with following examples:
 
   ==>
 
-  ```scala sc-compile-with:2
+  ```scala sc-compile-with:Box.scala
   abstract class C:
     val name: String
     def getNames(prefix: String | Null): java.util.List[String] // we still need to nullify the paramter types

docs/docs/reference/other-new-features/export.md

@@ -163,19 +163,19 @@ ImportSelectors   ::=  NamedSelector [‘,’ ImportSelectors]
 Export clauses raise questions about the order of elaboration during type checking.
 Consider the following example:
 
-```scala sc-id:1
+```scala sc-name:Base.scala
 class B { val c: Int = ??? }
 object a { val b = new B }
 ```
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 export a.*
 export b.*
 ```
 
 Is the `export b.*` clause legal? If yes, what does it export? Is it equivalent to `export a.b.*`? What about if we swap the last two clauses?
 
-```scala sc:fail sc-compile-with:1
+```scala sc:fail sc-compile-with:Base.scala
 export b.*
 export a.*
 ```

docs/docs/reference/other-new-features/indentation-experimental.md

@@ -92,14 +92,14 @@ IndentedArgument ::=  indent (CaseClauses | Block) outdent
 Note that a lambda argument must have the `=>` at the end of a line for braces
 to be optional. For instance, the following would also be incorrect:
 
-```scala sc-id:1
+```scala sc-name:Base.scala
 val xs: Seq[Int]
 ```
 
-```scala sc:fail sc-compile-with:1
+```scala sc:fail sc-compile-with:Base.scala
   xs.map x => x + 1   // error: braces or parentheses are required
 ```
 The lambda has to be enclosed in braces or parentheses:
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
   xs.map(x => x + 1)  // ok
 ```

docs/docs/reference/other-new-features/matchable.md

@@ -119,7 +119,7 @@ is guaranteed to succeed at run-time since `Any` and `Matchable` both erase to
 
 For instance, consider the definitions
 
-```scala sc-id:1
+```scala sc-name:Meter.scala
 opaque type Meter = Double
 def Meter(x: Double) = x
 
@@ -129,13 +129,13 @@ def Second(x: Double) = x
 
 Here, universal `equals` will return true for
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Meter.scala
 Meter(10).equals(Second(10))
 ```
 
 even though this is clearly false mathematically. With [multiversal equality](../contextual/multiversal-equality.md) one can mitigate that problem somewhat by turning
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Meter.scala
 Meter(10) == Second(10)
 ```
 

docs/docs/reference/other-new-features/opaques.md

@@ -5,7 +5,7 @@ title: "Opaque Type Aliases"
 
 Opaque types aliases provide type abstraction without any overhead. Example:
 
-```scala sc-id:1
+```scala sc-name:MyMath.scala
 object MyMath:
 
   opaque type Logarithm = Double
@@ -40,7 +40,7 @@ The public API of `Logarithm` consists of the `apply` and `safe` methods defined
 They convert from `Double`s to `Logarithm` values. Moreover, an operation `toDouble` that converts the other way, and operations `+` and `*` are defined as extension methods on `Logarithm` values.
 The following operations would be valid because they use functionality implemented in the `MyMath` object.
 
-```scala sc-compile-with:1
+```scala sc-compile-with:MyMath.scala
 import MyMath.Logarithm
 
 val l = Logarithm(1.0)
@@ -51,7 +51,7 @@ val l4 = l + l2
 
 But the following operations would lead to type errors:
 
-```scala sc:fail sc-compile-with:1
+```scala sc:fail sc-compile-with:MyMath.scala
 import MyMath.Logarithm
 
 val l = Logarithm(1.0)
@@ -65,7 +65,7 @@ l / l2                  // error: `/` is not a member of Logarithm
 
 Opaque type aliases can also come with bounds. Example:
 
-```scala sc-id:2
+```scala sc-name:Access.scala
 object Access:
 
   opaque type Permissions = Int
@@ -112,7 +112,7 @@ All three opaque type aliases have the same underlying representation type `Int`
 it known outside the `Access` object that `Permission` is a subtype of the other
 two types.  Hence, the following usage scenario type-checks.
 
-```scala sc-compile-with:2
+```scala sc-compile-with:Access.scala
 object User:
   import Access.*
 
@@ -141,7 +141,7 @@ since `Permissions` and `PermissionChoice` are different, unrelated types outsid
 While typically, opaque types are used together with objects to hide implementation details of a module, they can also be used with classes.
 
 For example, we can redefine the above example of Logarithms as a class.
-```scala sc-id:3
+```scala sc-name:Logarithms.scala
 class Logarithms:
 
   opaque type Logarithm = Double
@@ -155,7 +155,7 @@ class Logarithms:
 ```
 
 Opaque type members of different instances are treated as different:
-```scala sc:fail sc-compile-with:3
+```scala sc:fail sc-compile-with:Logarithms.scala
 val l1 = new Logarithms
 val l2 = new Logarithms
 val x = l1(1.5)

docs/docs/reference/other-new-features/parameter-untupling-spec.md

@@ -6,29 +6,29 @@ title: "Parameter Untupling - More Details"
 ## Motivation
 Say you have a list of pairs
 
-```scala sc-id:1
+```scala sc-name:Base.scala
 val xs: List[(Int, Int)]
 ```
 
 and you want to map `xs` to a list of `Int`s so that each pair of numbers is mapped to their sum.
 Previously, the best way to do this was with a pattern-matching decomposition:
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 xs.map {
   case (x, y) => x + y
 }
 ```
 While correct, this is inconvenient. Instead, we propose to write it the following way:
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 xs.map {
   (x, y) => x + y
 }
 ```
 
 or, equivalently:
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 xs.map(_ + _)
 ```
 

docs/docs/reference/other-new-features/parameter-untupling.md

@@ -5,14 +5,14 @@ title: "Parameter Untupling"
 
 Say you have a list of pairs
 
-```scala sc-id:1
+```scala sc-name:Base.scala
 val xs: List[(Int, Int)]
 ```
 
 and you want to map `xs` to a list of `Int`s so that each pair of numbers is mapped to
 their sum. Previously, the best way to do this was with a pattern-matching decomposition:
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 xs map {
   case (x, y) => x + y
 }
@@ -21,15 +21,15 @@ xs map {
 While correct, this is also inconvenient and confusing, since the `case`
 suggests that the pattern match could fail. As a shorter and clearer alternative Scala 3 now allows
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 xs.map {
   (x, y) => x + y
 }
 ```
 
 or, equivalently:
 
-```scala sc-compile-with:1
+```scala sc-compile-with:Base.scala
 xs.map(_ + _)
 ```
 

docs/docs/reference/other-new-features/trait-parameters.md

@@ -5,7 +5,7 @@ title: "Trait Parameters"
 
 Scala 3 allows traits to have parameters, just like classes have parameters.
 
-```scala sc-id:1
+```scala sc-name:Greeting.scala
 trait Greeting(val name: String):
   def msg = s"How are you, $name"
 
@@ -19,7 +19,7 @@ One potential issue with trait parameters is how to prevent
 ambiguities. For instance, you might try to extend `Greeting` twice,
 with different parameters.
 
-```scala sc:fail sc-compile-with:1
+```scala sc:fail sc-compile-with:Greeting.scala
 class D extends C, Greeting("Bill") // error: parameter passed twice
 ```
 
@@ -34,21 +34,21 @@ because it violates the second rule of the following for trait parameters:
 
 Here's a trait extending the parameterized trait `Greeting`.
 
-```scala sc-compile-with:1 sc-id:2
+```scala sc-compile-with:Greeting.scala sc-name:FormalGreeting.scala
 trait FormalGreeting extends Greeting:
   override def msg = s"How do you do, $name"
 ```
 As is required, no arguments are passed to `Greeting`. However, this poses an issue
 when defining a class that extends `FormalGreeting`:
 
-```scala sc:fail sc-compile-with:2
+```scala sc:fail sc-compile-with:FormalGreeting.scala
 class E extends FormalGreeting // error: missing arguments for `Greeting`.
 ```
 
 The correct way to write `E` is to extend both `Greeting` and
 `FormalGreeting` (in either order):
 
-```scala sc-compile-with:2
+```scala sc-compile-with:FormalGreeting.scala
 class E extends Greeting("Bob"), FormalGreeting
 ```