Update SIPs state

Author: scala-improvement-bot

_sips/sips/alternative-bind-patterns.md

@@ -0,0 +1,331 @@
+---
+layout: sip
+permalink: /sips/:title.html
+stage: pre-sip
+status: submitted
+presip-thread: https://contributors.scala-lang.org/t/pre-sip-bind-variables-for-alternative-patterns/6321/13
+title: SIP-60 - Bind variables within alternative patterns
+---
+
+**By: Yilin Wei**
+
+## History
+
+| Date          | Version            |
+|---------------|--------------------|
+| Sep 17th 2023 | Initial Draft      |
+| Jan 16th 2024 | Amendments         |
+
+## Summary
+
+Pattern matching is one of the most commonly used features in Scala by beginners and experts alike. Most of
+the features of pattern matching compose beautifully — for example, a user who learns about bind variables
+and guard patterns can mix the two features intuitively.
+
+One of the few outstanding cases where this is untrue, is when mixing bind variables and alternative patterns. The part of
+current [specification](https://scala-lang.org/files/archive/spec/2.13/08-pattern-matching.html) which we are concerned with is under section **8.1.12** and is copied below, with the relevant clause
+highlighted.
+
+> … All alternative patterns are type checked with the expected type of the pattern. **They may not bind variables other than wildcards**. The alternative …
+
+We propose that this restriction be lifted and this corner case be eliminated.
+
+Removing the corner case would make the language easier to teach, reduce friction and allow users to express intent in a more natural manner.
+
+## Motivation
+
+## Scenario
+
+The following scenario is shamelessly stolen from [PEP 636](https://peps.python.org/pep-0636), which introduces pattern matching to the
+Python language.
+
+Suppose a user is writing classic text adventure game such as [Zork](https://en.wikipedia.org/wiki/Zork). For readers unfamiliar with
+text adventure games, the player typically enters freeform text into the terminal in the form of commands to interact with the game
+world. Examples of commands might be `"pick up rabbit"` or `"open door"`.
+
+Typically, the commands are tokenized and parsed. After a parsing stage we may end up with a encoding which is similar to the following:
+
+```scala
+enum Word
+  case Get, North, Go, Pick, Up
+  case Item(name: String)
+    
+  case class Command(words: List[Word])
+```
+
+In this encoding, the string `pick up jar`, would be parsed as `Command(List(Pick, Up, Item("jar")))`.
+
+Once the command is parsed, we want to actually *do* something with the command. With this particular encoding,
+we would naturally reach for a pattern match — in the simplest case, we could get away with a single recursive function for
+our whole program.
+
+Suppose we take the simplest example where we want to match on a command like `"north"`. The pattern match consists of
+matching on a single stable identifier, `North` and the code would look like this:
+
+~~~ scala
+import Command.*
+    
+def loop(cmd: Command): Unit =
+  cmd match
+    case Command(North :: Nil) => // Code for going north
+~~~
+
+However as we begin play-testing the actual text adventure, we observe that users type `"go north"`. We decide
+our program should treat the two distinct commands as synonyms. At this point we would reach for an alternative pattern `|` and
+refactor the code like so:
+
+~~~ scala
+  case Command(North :: Nil | Go :: North :: Nil) => // Code for going north
+~~~
+
+This clearly expresses our intent that the two commands map to the same underlying logic.
+
+Later we decide that we want more complex logic in our game; perhaps allowing the user to pick up
+items with a command like `pick up jar`. We would then extend our function with another case, binding the variable `name`:
+
+~~~ scala
+  case Command(Pick :: Up :: Item(name) :: Nil) => // Code for picking up items
+~~~
+
+Again, we might realise through our play-testing that users type `get` as a synonym for `pick up`. After playing around
+with alternative patterns, we may reasonably write something like:
+
+~~~ scala
+  case Command(Pick :: Up :: Item(name) :: Nil | Get :: Item(name) :: Nil) => // Code for picking up items
+~~~
+
+Unfortunately at this point, we are stopped in our tracks by the compiler. The bind variable for `name` cannot be used in conjunction with alternative patterns.
+We must either choose a different encoding. We carefully consult the specification and that this is not possible.
+
+We can, of course, work around it by hoisting the logic to a helper function to the nearest scope which function definitions:
+
+~~~ scala
+def loop(cmd: Cmd): Unit =
+  def pickUp(item: String): Unit = // Code for picking up item
+    cmd match
+      case Command(Pick :: Up :: Item(name)) => pickUp(name)
+      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. 
+
+## Commentary
+
+Removing the restriction leads to more obvious encodings in the case of alternative patterns. Arguably, the language
+would be simpler and easier to teach — we do not have to remember that bind patterns and alternatives
+do not mix and need to teach newcomers the workarounds.
+
+For languages which have pattern matching, a significant number also support the same feature. Languages such as [Rust](https://github.com/rust-lang/reference/pull/957) and [Python](https://peps.python.org/pep-0636/#or-patterns) have
+supported it for some time. While
+this is not a great reason for Scala to do the same, having the feature exist in other languages means that users
+that are more likely to expect the feature.
+
+A smaller benefit for existing users, is that removing the corner case leads to code which is
+easier to review; the absolute code difference between adding a bind variable within an alternative versus switching to a different
+encoding entirely is smaller and conveys the intent of such changesets better.
+
+It is acknowledged, however, that such cases where we share the same logic with an alternative branches are relatively rare compared to
+the usage of pattern matching in general. The current restrictions are not too arduous to workaround for experienced practitioners, which
+can be inferred from the relatively low number of comments from the original [issue](https://github.com/scala/bug/issues/182) first raised in 2007.
+
+To summarize, the main arguments for the proposal are to make the language more consistent, simpler and easier to teach. The arguments
+against a change are that it will be low impact for the majority of existing users.
+
+## Proposed solution
+
+Removing the alternative restriction means that we need to specify some additional constraints. Intuitively, we
+need to consider the restrictions on variable bindings within each alternative branch, as well as the types inferred
+for each binding within the scope of the pattern.
+
+## Bindings
+
+The simplest case of mixing an alternative pattern and bind variables, is where we have two `UnApply` methods, with
+a single alternative pattern. For now, we specifically only consider the case where each bind variable is of the same
+type, like so:
+
+~~~ scala
+enum Foo:
+  case Bar(x: Int)
+  case Baz(y: Int)
+    
+  def fun = this match
+    case Bar(z) | Baz(z) => ... // z: Int
+~~~
+
+For the expression to make sense with the current semantics around pattern matches, `z` must be defined in both branches; otherwise the
+case body would be nonsensical if `z` was referenced within it (see [missing variables](#missing-variables) for a proposed alternative).
+
+Removing the restriction would also allow recursive alternative patterns:
+
+~~~ scala
+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
+~~~
+
+Using an `Ident` within an `UnApply` is not the only way to introduce a binding within the pattern scope.
+We also expect to be able to use an explicit binding using an `@` like this:
+
+~~~ scala
+enum Foo:
+  case Bar()
+  case Baz(bar: Bar)
+    
+  def fun = this match 
+    case Baz(x) | x @ Bar() => ... // x: Foo.Bar
+~~~
+
+## Types
+
+We propose that the type of each variable introduced in the scope of the pattern be the least upper-bound of the type
+inferred within within each branch.
+
+~~~ scala
+enum Foo:
+  case Bar(x: Int)
+  case Baz(y: String)
+    
+  def fun = this match
+    case Bar(x) | Baz(x) => // x: Int | String
+~~~
+
+We do not expect any inference to happen between branches. For example, in the case of a GADT we would expect the second branch of
+the following case to match all instances of `Bar`, regardless of the type of `A`.
+
+~~~ scala
+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 
+~~~
+
+### Given bind variables
+
+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
+~~~
+
+This begs the question of what to do in the case of an explicit `@` binding where the user binds a variable to the same _name_ but to different types. We can either expose a `String | Int` within the contextual scope, or simply reject the code as invalid.
+
+~~~ scala
+  enum Foo:
+    case Bar(s: String)
+    case Baz(i: Int)
+    
+    def fun = this match
+      case Bar(x @ given String) | Baz(x @ given Int) => ???
+~~~
+
+To be consistent with the named bindings, we argue that the code should compile and a contextual variable added to the scope with the type of `String | Int`.
+
+### Quoted patterns
+
+[Quoted patterns](https://docs.scala-lang.org/scala3/guides/macros/quotes.html#quoted-patterns) will not be supported in this SIP and the behaviour of quoted patterns will remain the same as currently i.e. any quoted pattern appearing in an alternative pattern binding a variable or type variable will be rejected as illegal.
+
+### Alternatives
+
+#### Enforcing a single type for a bound variable
+
+We could constrain the type for each bound variable within each alternative branch to be the same type. Notably, this is what languages such as Rust, which do not have sub-typing do.
+
+However, since untagged unions are part of Scala 3 and the fact that both are represented by the `|`, it felt more natural to discard this restriction.
+
+#### 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`. 
+
+~~~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
+~~~
+
+In the author's subjective opinion, it is more natural to view the alternative arms as separate branches — which would be equivalent to the function below.
+
+~~~scala
+def test = this match
+  case Bar(id: Int) => id
+  case Baz(id) => id
+~~~
+
+On the other hand, if it is decided that each bound variable ought to be the same type, then arguably "sharing" explicit type ascriptions across branches would reduce boilerplate.
+
+#### Missing variables
+
+Unlike in other languages, we could assign a type, `A | Null`, to a bind variable which is not present in all of the alternative branches. Rust, for example, is constrained by the fact that the size of a variable must be known and untagged unions do not exist.
+
+Arguably, missing a variable entirely is more likely to be an error — the absence of a requirement for `var` declarations before assigning variables in Python means that beginners can easily assign variables to the wrong variable.
+
+It may be, that the enforcement of having to have the same bind variables within each branch ought to be left to a linter rather thana a hard restriction within the language itself.
+
+## Specification
+
+We do not believe there are any syntax changes since the current specification already allows the proposed syntax.
+
+We propose that the following clauses be added to the specification:
+
+Let $`p_1 | \ldots | p_n`$ be an alternative pattern at an arbitrary depth within a case pattern and $`\Gamma_n`$ is the named scope associated with each alternative.
+
+If `p_i` is a quoted pattern binding a variable or type variable, the alternative pattern is considered invalid. Otherwise, let the named variables introduced within each alternative $`p_n`$, be $`x_i \in \Gamma_n`$ and the unnamed contextual variables within each alternative have the type $`T_i \in \Gamma_n`$.
+
+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 
+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.
+
+## Compatibility
+
+We believe the changes would be backwards compatible.
+
+# Related Work
+
+The language feature exists in multiple languages. Of the more popular languages, Rust added the feature in [2021](https://github.com/rust-lang/reference/pull/957) and
+Python within [PEP 636](https://peps.python.org/pep-0636/#or-patterns), the pattern matching PEP in 2020. Of course, Python is untyped and Rust does not have sub-typing
+but the semantics proposed are similar to this proposal.
+
+Within Scala, the [issue](https://github.com/scala/bug/issues/182) first raised in 2007. The author is also aware of attempts to fix this issue by [Lionel Parreaux](https://github.com/dotty-staging/dotty/compare/main...LPTK:dotty:vars-in-pat-alts) and the associated [feature request](https://github.com/lampepfl/dotty-feature-requests/issues/12) which
+was not submitted to the main dotty repository.
+
+The associated [thread](https://contributors.scala-lang.org/t/pre-sip-bind-variables-for-alternative-patterns/6321) has some extra discussion around semantics. Historically, there have been multiple similar suggestions — in [2023](https://contributors.scala-lang.org/t/qol-sound-binding-in-pattern-alternatives/6226) by Quentin Bernet and in [2021](https://contributors.scala-lang.org/t/could-it-be-possible-to-allow-variable-binging-in-patmat-alternatives-for-scala-3-x/5235) by Alexey Shuksto.
+
+## Implementation
+
+The author has a current in-progress implementation focused on the typer which compiles the examples with the expected types. Interested
+ parties are welcome to see the WIP [here](https://github.com/lampepfl/dotty/compare/main...yilinwei:dotty:main).
+
+### Further work
+
+#### Quoted patterns
+
+More investigation is needed to see how quoted patterns with bind variables in alternative patterns could be supported.
+
+## Acknowledgements
+
+Many thanks to **Zainab Ali** for proof-reading the draft, **Nicolas Stucki** and **Guillaume Martres** for their pointers on the dotty
+compiler codebase.

_sips/sips/alternative-bind-variables.md

@@ -0,0 +1,381 @@
+---
+layout: sip
+permalink: /sips/:title.html
+stage: design
+status: submitted
+title: SIP-62 - For comprehension improvements
+---
+
+**By: Kacper Korban (VirtusLab)**
+
+## History
+
+| Date          | Version            |
+|---------------|--------------------|
+| June 6th 2023 | Initial Draft      |
+| Feb 15th 2024 | Reviewed Version   |
+
+## Summary
+
+`for`-comprehensions in Scala 3 improved their usability in comparison to Scala 2, but there are still some pain points relating both usability of `for`-comprehensions and simplicity of their desugaring.
+
+This SIP tries to address some of those problems, by changing the specification of `for`-comprehensions. From user perspective, the biggest change is allowing aliases at the start of the `for`-comprehensions. e.g.
+
+```
+for {
+  x = 1
+  y <- Some(2)
+} yield x + y
+```
+
+## Motivation
+
+There are some clear pain points related to Scala'3 `for`-comprehensions and those can be divided into two categories:
+
+1. User-facing and code simplicity problems
+
+    Specifically, for the following example written in a Haskell-style do-comprehension
+
+    ```haskell
+    do
+      a = largeExpr(arg)
+      b <- doSth(a)
+      combineM(a, b)
+    ```
+    in Scala we would have to write
+
+    ```scala
+    val a = largeExpr(b)
+    for
+      b <- doSth(a)
+      x <- combineM(a, b)
+      yield x
+    ```
+
+    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.
+    ```scala
+    for
+      a <- doSth(arg)
+      b = a
+    yield a + b
+    ```
+
+    Intuition would suggest for the desugared code will be of the form
+
+    ```scala
+    doSth(arg).map { a =>
+      val b = a
+      a + b
+    }
+    ```
+
+    But because of the possibility of an `if` guard being immediately after the pure alias, the desugared code is of the form
+
+    ```scala
+    doSth(arg).map { a =>
+      val b = a
+      (a, b)
+    }.map { case (a, b) =>
+      a + b
+    }
+    ```
+
+    These unnecessary assignments and additional function calls not only add unnecessary runtime overhead but can also block other optimizations from being performed.
+
+## Proposed solution
+
+This SIP suggests the following changes to `for` comprehensions:
+
+1. Allow `for` comprehensions to start with pure aliases
+  
+    e.g.
+    ```scala
+    for
+      a = 1
+      b <- Some(2)
+      c <- doSth(a)
+    yield b + c
+    ```
+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. 
+    ```scala
+    for
+      a <- doSth(arg)
+      b = a
+    yield a + b
+    ```
+
+    will be desugared to
+
+    ```scala
+    doSth(arg).map { a =>
+      val b = a
+      a + b
+    }
+    ```
+
+    but
+
+    ```scala
+    for
+      a <- doSth(arg)
+      b = a
+      if b > 1
+    yield a + b
+    ```
+
+    will be desugared to
+
+    ```scala
+    doSth(arg).map { a =>
+      val b = a
+      (a, b)
+    }.withFilter { case (a, b) =>
+      b > 1
+    }.map { case (a, b) =>
+      a + b
+    }
+    ```
+
+3. Avoiding redundant `map` calls if the yielded value is the same as the last bound value.
+
+    e.g.
+    ```scala
+    for
+      a <- List(1, 2, 3)
+    yield a
+    ```
+
+    will just be desugared to
+
+    ```scala
+    List(1, 2, 3)
+    ```
+
+### Detailed description
+
+#### Ad 1. Allow `for` comprehensions to start with pure aliases
+
+Allowing `for` comprehensions to start with pure aliases is a straightforward change.
+
+The Enumerators syntax will be changed from:
+
+```
+Enumerators ::= Generator {semi Enumerator | Guard}
+```
+
+to
+
+```
+Enumerators ::= {Pattern1 `=' Expr semi} Generator {semi Enumerator | Guard}
+```
+
+Which will allow adding 0 or more aliases before the first generator.
+
+When desugaring is concerned, a for comprehension starting with pure aliases will generate a block with those aliases as `val` declarations and the rest of the desugared `for` as an expression. Unless the aliases are followed by a guard, then the desugaring should result in an error.
+
+New desugaring rule will be added:
+
+```scala
+For any N:
+  for (P_1 = E_1; ... P_N = E_N; ...)
+    ==>
+  {
+    val x_2 @ P_2 = E_2
+    ...
+    val x_N @ P_N = E_N
+    for (...)
+  }
+```
+
+e.g.
+
+```scala
+for
+  a = 1
+  b <- Some(2)
+  c <- doSth(a)
+yield b + c
+```
+
+will desugar to
+
+```scala
+{
+  val a = 1
+  for
+    b <- Some(2)
+    c <- doSth(a)
+  yield b + c
+}
+```
+
+#### Ad 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.
+
+Currently, for consistency, all pure aliases are desugared as if they are followed by an `if` condition. Which makes the desugaring more complicated than expected.
+
+e.g.
+
+The following code:
+
+```scala
+for
+  a <- doSth(arg)
+  b = a
+yield a + b
+```
+
+will be desugared to:
+
+```scala
+doSth(arg).map { a =>
+  val b = a
+  (a, b)
+}.map { case (a, b) =>
+  a + b
+}
+```
+
+The proposed change is to introduce a simpler desugaring for common cases, when aliases aren't followed by a guard, and keep the old desugaring method for the other cases.
+
+A new desugaring rules will be introduced for simple desugaring.
+
+```scala
+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; ...)) 
+
+And:
+
+  for () yield E  ==>  E
+
+(Where empty for-comprehensions are excluded by the parser)
+```
+
+It delegares desugaring aliases to the newly introduced rule from the previous impreovement. i.e.
+
+```scala
+For any N:
+  for (P_1 = E_1; ... P_N = E_N; ...)
+    ==>
+  {
+    val x_2 @ P_2 = E_2
+    ...
+    val x_N @ P_N = E_N
+    for (...)
+  }
+```
+
+One other rule also has to be changed, so that the current desugaring method, of passing all the aliases in a tuple with the result, will only be used when desugaring a generator, followed by some aliases, followed by a guard.
+
+```scala
+For any N:
+  for (P <- G; P_1 = E_1; ... P_N = E_N; if E; ...)
+    ==>
+  for (TupleN(P, P_1, ... P_N) <-
+    for (x @ P <- G) yield {
+      val x_1 @ P_1 = E_2
+      ...
+      val x_N @ P_N = E_N
+      TupleN(x, x_1, ..., x_N)
+    }; if E; ...)
+```
+
+This changes will make the desugaring work in the following way:
+
+```scala
+for
+  a <- doSth(arg)
+  b = a
+yield a + b
+```
+
+will be desugared to
+
+```scala
+doSth(arg).map { a =>
+  val b = a
+  a + b
+}
+```
+
+but
+
+```scala
+for
+  a <- doSth(arg)
+  b = a
+  if b > 1
+yield a + b
+```
+
+will be desugared to
+
+```scala
+doSth(arg).map { a =>
+  val b = a
+  (a, b)
+}.withFilter { case (a, b) =>
+  b > 1
+}.map { case (a, b) =>
+  a + b
+}
+```
+
+#### Ad 3. Avoiding redundant `map` calls if the yielded value is the same as the last bound value.
+
+This change is strictly an optimization. This allows for the compiler to get rid of the final `map` call, if the yielded value is the same as the last bound pattern. The pattern can be either a single variable binding or a tuple.
+
+One desugaring rule has to be modified for this purpose.
+
+```scala
+  for (P <- G) yield P  ==>  G
+If P is a variable or a tuple of variables and G is not a withFilter.
+
+  for (P <- G) yield E  ==>  G.map (P => E)
+Otherwise
+```
+
+e.g.
+```scala
+for
+  a <- List(1, 2, 3)
+yield a
+```
+
+will just be desugared to
+
+```scala
+List(1, 2, 3)
+```
+
+### Compatibility
+
+This change may change the semantics of some programs. It may remove some `map` calls in the desugared code, which may change the program semantics (if the `map` implementation was side-effecting).
+
+For example the following code will now have only one `map` call, instead of two:
+```scala
+for
+  a <- doSth(arg)
+  b = a
+yield a + b
+```
+
+### Other concerns
+
+As far as I know, there are no widely used Scala 3 libraries that depend on the desugaring specification of `for`-comprehensions.
+
+## Links
+
+1. Scala contributors discussion thread (pre-SIP): https://contributors.scala-lang.org/t/pre-sip-improve-for-comprehensions-functionality/3509/51
+2. Github issue discussion about for desugaring: https://github.com/lampepfl/dotty/issues/2573
+3. Scala 2 implementation of some of the improvements: https://github.com/oleg-py/better-monadic-for
+4. Implementation of one of the simplifications: https://github.com/lampepfl/dotty/pull/16703
+5. Draft implementation branch: https://github.com/dotty-staging/dotty/tree/improved-fors

_sips/sips/better-fors.md

@@ -286,8 +286,18 @@ At the top level, `variance = 1` and `scrutIsWidenedAbstract = false`.
       * If `q` is a skolem type `∃α:X`, fail as not specific.
       * Otherwise, compute `matchPattern(ti, q.Y, 0, scrutIsWidenedAbstract)`.
     * Otherwise, the underlying type definition of `q.Y` is of the form `= U`:
-      * If `q` is a skolem type `∃α:X` and `U` refers to `α`, fail as not specific.
-      * Otherwise, compute `matchPattern(ti, U, 0, scrutIsWidenedAbstract)`.
+      * If `q` is not a skolem type `∃α:X`, compute `matchPattern(ti, U, 0, scrutIsWidenedAbstract)`.
+      * Otherwise, let `U' = dropSkolem(U)` be computed as follow:
+        * `dropSkolem(q)` is undefined.
+        * `dropSkolem(p.T) = p'.T` where `p' = dropSkolem(p)` if the latter is defined. Otherwise:
+          * If the underlying type of `p.T` is of the form `= V`, then `dropSkolem(V)`.
+          * Otherwise `dropSkolem(p.T)` is undefined.
+        * `dropSkolem(p.x) = p'.x` where `p' = dropSkolem(p)` if the latter is defined. Otherwise:
+          * If the dealiased underlying type of `p.x` is a singleton type `r.y`, then `dropSkolem(r.y)`.
+          * Otherwise `dropSkolem(p.x)` is undefined.
+        * For all other types `Y`, `dropSkolem(Y)` is the type formed by replacing each component `Z` of `Y` by `dropSkolem(Z)`.
+      * If `U'` is undefined, fail as not specific.
+      * Otherwise, compute `matchPattern(ti, U', 0, scrutIsWidenedAbstract)`.
   * If `T` is a concrete type alias to a type lambda:
     * Let `P'` be the beta-reduction of `P`.
     * Compute `matchPattern(P', X, variance, scrutIsWidenedAbstract)`.

_sips/sips/for-comprehension-improvements.md

@@ -1,7 +1,331 @@
 ---
-title: SIP-59 - Multiple assignments
-status: waiting-for-implementation
-pull-request-number: 73
+layout: sip
+permalink: /sips/:title.html
 stage: implementation
-
+status: waiting-for-implementation
+presip-thread: https://contributors.scala-lang.org/t/pre-sip-multiple-assignments/6425
+title: SIP-59 - Multiple Assignments
 ---
+
+**By: Dimi Racordon**
+
+## History
+
+| Date          | Version            |
+|---------------|--------------------|
+| Jan 17th 2024 | Initial Draft      |
+
+## Summary
+
+This proposal discusses the syntax and semantics of a construct to assign multiple variables with a single expression.
+This feature would simplify the implementation of operations expressed in terms of relationships between multiple variables, such as [`std::swap`](https://en.cppreference.com/w/cpp/algorithm/swap) in C++.
+
+## Motivation
+
+It happens that one has to assign multiple variables "at once" in an algorithm.
+For example, let's consider the Fibonacci sequence:
+
+```scala
+class FibonacciIterator() extends Iterator[Int]:
+
+  private var a: Int = 0
+  private var b: Int = 1
+
+  def hasNext = true
+  def next() =
+    val r = a
+    val n = a + b
+    a = b
+    b = n
+    r
+```
+
+The same iterator could be rewritten more concisely if we could assign multiple variables at once.
+For example, we can write the following in Swift:
+
+```swift
+struct FibonacciIterator: IteratorProtocol {
+
+  private var a: Int = 0
+  private var b: Int = 1
+  init() {}
+
+  mutating func next() -> Int? {
+    defer { (a, b) = (b, a + b) }
+    return a
+  }
+
+}
+```
+
+Though the differences may seem frivolous at first glance, they are in fact important.
+If we look at a formal definition of the Fibonacci sequence (e.g., on [Wikipedia](https://en.wikipedia.org/wiki/Fibonacci_sequence)), we might see something like:
+
+> The Fibonacci sequence is given by *F(n) = F(n-1) + F(n+1)* where *F(0) = 0* and *F(1) = 1*.
+
+Although this declarative description says nothing about an evaluation order, it becomes a concern in our Scala implementation as we must encode the relationship into multiple operational steps.
+This decomposition offers opportunities to get things wrong:
+
+```scala
+def next() =
+  val r = a
+  a = b
+  b = a + b // invalid semantics, the value of `a` changed "too early"
+  r
+```
+
+In contrast, our Swift implementation can remain closer to the formal definition and is therefore more legible and less error-prone.
+
+Multiple assignments show up in many general-purpose algorithms (e.g., insertion sort, partition, min-max element, ...).
+But perhaps the most fundamental one is `swap`, which consists of exchanging two values.
+
+We often swap values that are stored in some collection.
+In this particular case, all is well in Scala because we can ask the collection to swap elements at given positions:
+
+```scala
+extension [T](self: mutable.ArrayBuffer[T])
+  def swapAt(i: Int, j: Int) =
+    val t = self(i)
+    self(i) = self(j)
+    self(j) = t
+
+val a = mutable.ArrayBuffer(1, 2, 3)
+a.swapAt(0, 2)
+println(a) // ArrayBuffer(3, 2, 1)
+```
+
+Sadly, one can't implement a generic swap method that wouldn't rely on the ability to index a container.
+The only way to express this operation in Scala is to "inline" the pattern implemented by `swapAt` every time we need to swap two values.
+
+Having to rewrite this boilerplate is unfortunate.
+Here is an example in a realistic algorithm:
+
+```scala
+extension [T](self: Seq[T])(using Ordering[T])
+  def minMaxElements: Option[(T, T)] =
+    import math.Ordering.Implicits.infixOrderingOps
+
+    // Return None for collections smaller than 2 elements.
+    var i = self.iterator
+    if (!i.hasNext) { return None }
+    var l = i.next()
+    if (!i.hasNext) { return None }
+    var h = i.next()
+
+    // Confirm the initial bounds.
+    if (h < l) { val t = l; l = h; h = l }
+
+    // Process the remaining elements.
+    def loop(): Option[(T, T)] =
+      if (i.hasNext) {
+        val n = i.next()
+        if (n < l) { l = n } else if (n > h) { h = n }
+        loop()
+      } else {
+        Some((l, h))
+      }
+    loop()
+```
+
+*Note: implementation shamelessly copied from [swift-algorithms](https://github.com/apple/swift-algorithms/blob/main/Sources/Algorithms/MinMax.swift).*
+
+The swap occurs in the middle of the method with the sequence of expressions `val t = l; l = h; h = l`.
+To borrow from the words of Edgar Dijskstra [1, Chapter 11]:
+
+> [that] is combersome and ugly compared with the [multiple] assignment.
+
+While `swap` is a very common operation, it's only an instance of a more general class of operations that are expressed in terms of relationships between multiple variables.
+The definition of the Fibonacci sequence is another example.
+
+## Proposed solution
+
+The proposed solution is to add a language construct to assign multiple variables in a single expression.
+Using this construct, swapping two values can be written as follows:
+
+```scala
+var a = 2
+var b = 4
+(a, b) = (b, a)
+println(s"$a$b") // 42
+```
+
+The above Fibonacci iterator can be rewritten as follows:
+
+```scala
+class FibonacciIterator() extends Iterator[Int]:
+
+  private var a: Int = 0
+  private var b: Int = 1
+
+  def hasNext = true
+  def next() =
+    val r = a
+    (a, b) = (b, a + b)
+    r
+```
+
+Multiple assignments also alleviate the need for a swap method on collections, as the same idiomatic pattern can be reused to exchange elements at given indices:
+
+```scala
+val a = mutable.ArrayBuffer(1, 2, 3)
+(a(0), a(2)) = (a(2), a(0))
+println(a) // ArrayBuffer(3, 2, 1)
+```
+
+### Specification
+
+A multiple assignment is an expression of the form `AssignTarget ‘=’ Expr` where:
+
+```
+AssignTarget ::= ‘(’ AssignTargetNode {‘,’ AssignTargetNode} ‘)’
+AssignTargetNode ::= Expr | AssignTarget
+```
+
+An assignment target describes a structural pattern that can only be matched by a compatible composition of tuples.
+For example, the following program is legal.
+
+```scala
+def f: (Boolean, Int) = (true, 42)
+val a = mutable.ArrayBuffer(1, 2, 3)
+def b = a
+var x = false
+
+(x, a(0)) = (false, 1337)
+(x, a(1)) = f
+((x, a(1)), b(2)) = (f, 9000)
+(x) = Tuple1(false)
+```
+
+A mismatch between the structure of a multiple assignment's target and the result of its RHS is a type error.
+It cannot be detected during parsing because at this stage the compiler would not be able to determine the shape of an arbitrary expression's result.
+For example, all multiple assignments in the following program are ill-typed:
+
+```scala
+def f: (Boolean, Int) = (true, 42)
+val a = mutable.ArrayBuffer(1, 2, 3)
+def b = a
+var x = false
+
+(a(1), x) = f               // type mismatch
+(x, a(1), b(2)) = (f, 9000) // structural mismatch
+(x) = false                 // structural mismatch
+(x) = (1, 2)                // structural mismatch
+```
+
+Likewise, `(x) = Tuple1(false)` is _not_ equivalent to `x = Tuple1(false)`.
+The former is a multiple assignment while the latter is a regular assignment, as described by the [current grammar](https://docs.scala-lang.org/scala3/reference/syntax.html) (see `Expr1`).
+Though this distinction is subtle, multiple assignments involving unary tuples should be rare.
+
+The operational semantics of multiple assignments (aka concurrent assignments) have been studied extensively in scienific literature (e.g., [1, 2]).
+A first intuition is that the most desirable semantics can be achieved by fully evaluating the RHS of the assignment before assigning any expression in the LHS [1].
+However, additional considerations must be given w.r.t. the independence of the variables on the LHS to guarantee deterministic results.
+For example, consider the following expression:
+
+```scala
+(x, x) = (1, 2)
+```
+
+While one may conclude that such an expression should be an error [1], it is in general difficult to guarantee value independence in a language with pervasive reference semantics.
+Further, it is desirable to write expressions of the form `(a(0), a(2)) = (a(2), a(0))`, as shown in the previous section.
+Another complication is that multiple assignments should uphold the general left-to-right evaluation semantics of the Scala language.
+For example, `a.b = c` requires `a` to be evaluated _before_ `c`.
+
+Note that regular assignments desugar to function calls (e.g., `a(b) = c` is sugar for `a.update(b, c)`).
+One property of these desugarings is always the last expression being evaluated before the method performing the assignment is called.
+Given this observation, we address the abovementioned issues by defining the following algorithm:
+
+1. Traverse the LHS structure in inorder and for each leaf:
+    - Evaluate each outermost subexpression to its value
+    - Form a closure capturing these values and accepting a single argument to perform the desugared assignment
+    - Associate that closure to the leaf
+2. Compute the value of the RHS, which forms a tree
+3. Traverse the LHS and RHS structures pairwise in inorder and for each leaf:
+    - Apply the closure formerly associated to the LHS on RHS value
+
+For instance, consider the following definitions.
+
+```scala
+def f: (Boolean, Int) = (true, 42)
+val a = mutable.ArrayBuffer(1, 2, 3)
+def b = a
+var x = false
+```
+
+The evaluation of the expression `((x, a(a(0))), b(2)) = (f, 9000)` is as follows:
+
+1. form a closure `f0 = (rhs) => x_=(rhs)`
+2. evaluate `a(0)`; result is `1`
+3. form a closure `f1 = (rhs) => a.update(1, rhs)`
+4. evaluate `b`; result is `a`
+5. evaluate `2`
+6. form a closure `f2 = (rhs) => a.update(2, rhs)`
+7. evaluate `(f, 9000)`; result is `((true, 42), 9000)`
+8. evaluate `f0(true)`
+9. evaluate `f1(42)`
+10. evaluate `f2(9000)`
+
+After the assignment, `x == true` and `a == List(1, 42, 9000)`.
+
+The compiler is allowed to ignore this procedure and generate different code for optimization purposes as long as it can guarantee that such a change is not observable.
+For example, given two local variables `x` and `y`, their assignments in `(x, y) = (1, 2)` can be reordered or even performed in parallel.
+
+### Compatibility
+
+This proposal is purely additive and have no backward binary or TASTy compatibility consequences.
+The semantics of the proposed new construct is fully expressible in terms of desugaring into current syntax, interpreteted with current semantics.
+
+The proposed syntax is not currently legal Scala.
+Therefore no currently existing program could be interpreted with different semantics using a newer compiler version supporting multiple assignments.
+
+### Other concerns
+
+One understandable concern of the proposed syntax is that the semantics of multiple assignments resembles that of pattern matching, yet it has different semantics.
+For example:
+
+```scala
+val (a(x), b) = (true, "!") // 1
+
+(a(x), b) = (true, "!")     // 2
+```
+
+If `a` is instance of a type with a companion extractor object, the two lines above have completely different semantics.
+The first declares two local bindings `x` and `b`, applying pattern matching to determine their value from the tuple `(true, "!")`.
+The second is assigning `a(x)` and `b` to the values `true` and `"!"`, respectively.
+
+Though possibly surprising, the difference in behavior is easy to explain.
+The first line applies pattern matching because it starts with `val`.
+The second doesn't because it involves no pattern matching introducer.
+Further, note that a similar situation can already be reproduced in current Scala:
+
+```scala
+val a(x) = true // 1
+
+a(x) = true     // 2
+```
+
+## Alternatives
+
+The current proposal supports arbitrary tree structures on the LHS of the assignment.
+A simpler alternative would be to only support flat sequences, allowing the syntax to dispense with parentheses.
+
+```scala
+a, b = b, a
+```
+
+While this approach is more lightweight, the reduced expressiveness inhibits potentially interesting use cases.
+Further, consistently using tuple syntax on both sides of the equality operator clearly distinguishes regular and multiple assignments.
+
+## Related work
+
+A Pre-SIP discussion took place prior to this proposal (see [here](https://contributors.scala-lang.org/t/pre-sip-multiple-assignments/6425/1)).
+
+Multiple assignments are present in many contemporary languages.
+This proposal already illustrated them in Swift, but they are also commonly used in Python.
+Multiple assigments have also been studied extensively in scienific literature (e.g., [1, 2]).
+
+## FAQ
+
+## References
+
+1. Edsger W. Dijkstra: A Discipline of Programming. Prentice-Hall 1976, ISBN 013215871X
+2. Ralph-Johan Back, Joakim von Wright: Refinement Calculus - A Systematic Introduction. Graduate Texts in Computer Science, Springer 1998, ISBN 978-0-387-98417-9