Update SIPs state

Author: scala-improvement-bot

_sips/sips/42.type.md

@@ -582,7 +582,7 @@ terms.
 
 ### Byte and short literals
 
-`Byte` and `Short` have singleton types, but lack any corresponding syntax either at the type or at the term level. 
+`Byte` and `Short` have singleton types, but lack any corresponding syntax either at the type or at the term level.
 These types are important in libraries which deal with low-level numerics and protocol implementation
 (see eg. [Spire](https://github.com/non/spire) and [Scodec](https://github.com/scodec/scodec)) and
 elsewhere, and the ability to, for instance, index a type class by a byte or short literal would be

_sips/sips/alternative-bind-variables.md

@@ -49,7 +49,7 @@ Typically, the commands are tokenized and parsed. After a parsing stage we may e
 enum Word
   case Get, North, Go, Pick, Up
   case Item(name: String)
-    
+
   case class Command(words: List[Word])
 ```
 
@@ -64,7 +64,7 @@ matching on a single stable identifier, `North` and the code would look like thi
 
 ~~~ scala
 import Command.*
-    
+
 def loop(cmd: Command): Unit =
   cmd match
     case Command(North :: Nil) => // Code for going north
@@ -107,7 +107,7 @@ def loop(cmd: Cmd): Unit =
       case Command(Get :: Item(name)) => pickUp(name)
 ~~~
 
-Or any number of different encodings. However, all of them are less intuitive and less obvious than the code we tried to write. 
+Or any number of different encodings. However, all of them are less intuitive and less obvious than the code we tried to write.
 
 ## Commentary
 
@@ -147,7 +147,7 @@ type, like so:
 enum Foo:
   case Bar(x: Int)
   case Baz(y: Int)
-    
+
   def fun = this match
     case Bar(z) | Baz(z) => ... // z: Int
 ~~~
@@ -161,11 +161,11 @@ Removing the restriction would also allow recursive alternative patterns:
 enum Foo:
   case Bar(x: Int)
   case Baz(x: Int)
-    
+
 enum Qux:
   case Quux(y: Int)
   case Corge(x: Foo)
-    
+
   def fun = this match
     case Quux(z) |  Corge(Bar(z) | Baz(z)) => ... // z: Int
 ~~~
@@ -177,8 +177,8 @@ We also expect to be able to use an explicit binding using an `@` like this:
 enum Foo:
   case Bar()
   case Baz(bar: Bar)
-    
-  def fun = this match 
+
+  def fun = this match
     case Baz(x) | x @ Bar() => ... // x: Foo.Bar
 ~~~
 
@@ -191,7 +191,7 @@ inferred within within each branch.
 enum Foo:
   case Bar(x: Int)
   case Baz(y: String)
-    
+
   def fun = this match
     case Bar(x) | Baz(x) => // x: Int | String
 ~~~
@@ -203,26 +203,26 @@ the following case to match all instances of `Bar`, regardless of the type of `A
 enum Foo[A]:
   case Bar(a: A)
   case Baz(i: Int) extends Foo[Int]
-    
+
   def fun = this match
-    case Baz(x) | Bar(x) => // x: Int | A 
+    case Baz(x) | Bar(x) => // x: Int | A
 ~~~
 
 ### Given bind variables
 
-It is possible to introduce bindings to the contextual scope within a pattern match branch. 
+It is possible to introduce bindings to the contextual scope within a pattern match branch.
 
 Since most bindings will be anonymous but be referred to within the branches, we expect the _types_ present in the contextual scope for each branch to be the same rather than the _names_.
 
 ~~~ scala
   case class Context()
-  
+
   def run(using ctx: Context): Unit = ???
-  
+
   enum Foo:
     case Bar(ctx: Context)
     case Baz(i: Int, ctx: Context)
-    
+
     def fun = this match
       case Bar(given Context) | Baz(_, given Context) => run // `Context` appears in both branches
 ~~~
@@ -233,7 +233,7 @@ This begs the question of what to do in the case of an explicit `@` binding wher
   enum Foo:
     case Bar(s: String)
     case Baz(i: Int)
-    
+
     def fun = this match
       case Bar(x @ given String) | Baz(x @ given Int) => ???
 ~~~
@@ -254,13 +254,13 @@ However, since untagged unions are part of Scala 3 and the fact that both are re
 
 #### Type ascriptions in alternative branches
 
-Another suggestion is that an _explicit_ type ascription by a user ought to be defined for all branches. For example, in the currently proposed rules, the following code would infer the return type to be `Int | A` even though the user has written the statement `id: Int`. 
+Another suggestion is that an _explicit_ type ascription by a user ought to be defined for all branches. For example, in the currently proposed rules, the following code would infer the return type to be `Int | A` even though the user has written the statement `id: Int`.
 
 ~~~scala
 enum Foo[A]:
   case Bar[A](a: A)
   case Baz[A](a: A)
-  
+
   def test = this match
     case Bar(id: Int) | Baz(id) => id
 ~~~
@@ -295,7 +295,7 @@ If `p_i` is a quoted pattern binding a variable or type variable, the alternativ
 
 Each $`p_n`$ must introduce the same set of bindings, i.e. for each $`n`$, $`\Gamma_n`$ must have the same **named** members $`\Gamma_{n+1}`$ and the set of $`{T_0, ... T_n}`$ must be the same.
 
-If $`X_{n,i}`$, is the type of the binding $`x_i`$ within an alternative $`p_n`$, then the consequent type, $`X_i`$, of the 
+If $`X_{n,i}`$, is the type of the binding $`x_i`$ within an alternative $`p_n`$, then the consequent type, $`X_i`$, of the
 variable $`x_i`$ within the pattern scope, $`\Gamma`$ is the least upper-bound of all the types $`X_{n, i}`$ associated with
 the variable, $`x_i`$ within each branch.
 

_sips/sips/better-fors.md

@@ -54,7 +54,7 @@ There are some clear pain points related to Scala'3 `for`-comprehensions and tho
 
     This complicates the code, even in this simple example.
 2. The simplicity of desugared code
-    
+
     The second pain point is that the desugared code of `for`-comprehensions can often be surprisingly complicated.
 
     e.g.
@@ -92,7 +92,7 @@ There are some clear pain points related to Scala'3 `for`-comprehensions and tho
 This SIP suggests the following changes to `for` comprehensions:
 
 1. Allow `for` comprehensions to start with pure aliases
-  
+
     e.g.
     ```scala
     for
@@ -103,7 +103,7 @@ This SIP suggests the following changes to `for` comprehensions:
     ```
 2. Simpler conditional desugaring of pure aliases. i.e. whenever a series of pure aliases is not immediately followed by an `if`, use a simpler way of desugaring.
 
-    e.g. 
+    e.g.
     ```scala
     for
       a <- doSth(arg)
@@ -250,7 +250,7 @@ A new desugaring rules will be introduced for simple desugaring.
 For any N:
   for (P <- G; P_1 = E_1; ... P_N = E_N; ...)
     ==>
-  G.flatMap (P => for (P_1 = E_1; ... P_N = E_N; ...)) 
+  G.flatMap (P => for (P_1 = E_1; ... P_N = E_N; ...))
 
 And:
 

_sips/sips/byname-implicits.md

@@ -167,7 +167,7 @@ object Semigroup {
     }
 }
 ```
-  
+
 then we can manually write instances for, for example, tuples of types which have `Semigroup`
 instances,
 
@@ -387,7 +387,7 @@ val showListInt: Show[List[Int]] =
       showUnit
     )
   )
-```  
+```
 
 where at least one argument position between the val definition and the recursive occurrence of
 `showListInt` is byname.
@@ -499,16 +499,16 @@ any _T<sub>j</sub>_, where _i_ < _j_.
 The essence of the algorithm described in the Scala Language Specification is as follows,
 
 > Call the sequence of open implicit types _O_. This is initially empty.
-> 
-> To resolve an implicit of type _T_ given stack of open implicits _O_, 
-> 
+>
+> To resolve an implicit of type _T_ given stack of open implicits _O_,
+>
 > + Identify the definition _d_ which satisfies _T_.
-> 
+>
 > + If the core type of _T_ dominates any element of _O_ then we have observed divergence and we're
 >   done.
-> 
+>
 > + If _d_ has no implicit arguments then the result is the value yielded by _d_.
-> 
+>
 > + Otherwise for each implicit argument _a_ of _d_, resolve _a_ against _O+T_, and the result is the
 >   value yielded by _d_ applied to its resolved arguments.
 
@@ -550,15 +550,15 @@ divergence check across the set of relevant implicit definitions.
 
 This gives us the following,
 
-> To resolve an implicit of type _T_ given stack of open implicits _O_, 
-> 
+> To resolve an implicit of type _T_ given stack of open implicits _O_,
+>
 > + Identify the definition _d_ which satisfies _T_.
-> 
+>
 > + If the core type of _T_ dominates the type _U_ of some element _<d, U>_ of _O_ then we have
 >   observed divergence and we're done.
-> 
+>
 > + If _d_ has no implicit arguments then the result is the value yielded by _d_.
-> 
+>
 > + Otherwise for each implicit argument _a_ of _d_, resolve _a_ against _O+<d, T>_, and the result is
 >   the value yielded by _d_ applied to its resolved arguments.
 
@@ -646,8 +646,8 @@ larger than _U_ despite using only elements that are present in _U_.
 
 This gives us the following,
 
-> To resolve an implicit of type _T_ given stack of open implicits _O_, 
-> 
+> To resolve an implicit of type _T_ given stack of open implicits _O_,
+>
 > + Identify the definition _d_ which satisfies _T_.
 >
 > + if there is an element _e_ of _O_ of the form _<d, T>_ such that at least one element between _e_
@@ -658,7 +658,7 @@ This gives us the following,
 >   observed divergence and we're done.
 >
 > + If _d_ has no implicit arguments then the result is the value yielded by _d_.
-> 
+>
 > + Otherwise for each implicit argument _a_ of _d_, resolve _a_ against _O+<d, T>_, and the result is
 >   the value yielded by _d_ applied to its resolved arguments.
 

_sips/sips/clause-interleaving.md

@@ -2,7 +2,7 @@
 layout: sip
 title: SIP-47 - Clause Interleaving
 stage: completed
-status: accepted
+status: shipped
 permalink: /sips/:title.html
 ---
 
@@ -71,7 +71,7 @@ This definition provides the expected source API at call site, but it has two is
 
 Another workaround is to return a polymorphic function, for example:
 ~~~scala
-def getOrElse(k:Key): [V >: k.Value] => (default: V) => V = 
+def getOrElse(k:Key): [V >: k.Value] => (default: V) => V =
     [V] => (default: V) => ???
 ~~~
 While again, this provides the expected API at call site, it also has issues:

_sips/sips/drop-stdlib-forwards-bin-compat.md

@@ -210,7 +210,7 @@ repositories {
 dependencies {
     implementation 'org.scala-lang:scala-library:2.13.8'
     implementation 'com.softwaremill.sttp.client3:core_2.13:3.8.3'
-    implementation 'com.softwaremill.sttp.shared:ws_2.13:1.2.7' 
+    implementation 'com.softwaremill.sttp.shared:ws_2.13:1.2.7'
 }
 $> gradle dependencies --configuration runtimeClasspath
 

_sips/sips/fewer-braces.md

@@ -2,7 +2,7 @@
 layout: sip
 permalink: /sips/:title.html
 stage: completed
-status: accepted
+status: shipped
 title: SIP-44 - Fewer Braces
 ---
 

_sips/sips/interpolation-quote-escape.md

@@ -38,7 +38,7 @@ escape a `"` character to represent a literal `"` withing a string.
 ## Motivating Example
 
 That the `"` character can't be easily escaped in interpolations has been an
-open issue since at least 2012[^1], and how to deal with this issue is a 
+open issue since at least 2012[^1], and how to deal with this issue is a
 somewhat common SO question[^2][^3]
 
 {% highlight Scala %}

_sips/sips/match-types-spec.md

@@ -2,7 +2,7 @@
 layout: sip
 permalink: /sips/:title.html
 stage: completed
-status: accepted
+status: shipped
 title: SIP-56 - Proper Specification for Match Types
 ---
 

_sips/sips/multi-source-extension-overloads.md

@@ -2,7 +2,7 @@
 layout: sip
 permalink: /sips/:title.html
 stage: completed
-status: accepted
+status: shipped
 title: SIP-54 - Multi-Source Extension Overloads
 ---
 

_sips/sips/named-tuples.md

@@ -1,8 +1,8 @@
 ---
 layout: sip
 permalink: /sips/named-tuples.html
-stage: implementation
-status: under-review
+stage: completed
+status: shipped
 presip-thread: https://contributors.scala-lang.org/t/pre-sip-named-tuples/6403/164
 title: SIP-58 - Named Tuples
 ---