Added more alternatives

Author: Jentsch

_sips/sips/2021-06-25-pattern-matching-with-named-fields.md renamed to _sips/sips/2022-02-25-pattern-matching-with-named-fields.md

@@ -8,17 +8,15 @@ redirect_from: /sips/pending/2021-06-25-named-pattern-matching.html
 
 ## History
 
-| Date           | Version       |
-|----------------|---------------|
-| June 25th 2015 | Initial Draft |
+| Date          | Version       |
+|---------------|---------------|
+| Feb 25th 2022 | Initial Draft |
 
 ## Motivation
 
-An intuitive, readable, and extendible way to deconstruct case classes in pattern matching.
+An readable, extendible, and intuitive way to deconstruct case classes in pattern matching.
 
-// TODO: many times requested, find more references than the contributors thread
-
-// TODO: use lingo of spec
+Link to work in progress implementation lives here: https://github.com/Jentsch/dotty
 
 ## Motivating Examples
 
@@ -33,7 +31,7 @@ val annasCity = user match
   case User(name = "Anna", city = c) => c
 ```
 
-The Deconstruction allows the same syntax as the construction and seems to be what people intuitive expect. See //TODO: Examples
+The Deconstruction allows the same syntax as the construction and seems to be what people intuitively expect. See for example the very first post in [Scala Contributors Thread][contributors-thread] for this topic.
 
 Without names in patterns user have to use underscore a lot. The example above would be written as, and is the same what the compiler generates:
 
@@ -44,13 +42,13 @@ val annasCity = user match
   case User("Anna", _, c) => c
 ```
 
-This makes it hard which parameter means what, basically the same idea as for named arguments. (IDEs help here, by showing the names.)
+This makes it hard which parameter means what, basically the same idea as for named arguments. Adding underscores until the compile is happy is also not a great experience. IDEs can help here, by showing the names.
 
-In addition, it breaks every time a field of `User` gets added, rearranged, or removed.
-In the worst case it breaks silently, if two fields with the type switch places.
+In addition, the code breaks every time a field of `User` gets added, rearranged, or removed.
+In the worst case it breaks silently, if two fields with the same type switch places.
 
-Personal motivation comes from using to offend https://www.scalatest.org/user_guide/using_matchers#matchingAPattern
-and got bitten every time the data model changed slightly.
+My personal motivation comes from using [`matchPattern` in ScalaTest](https://www.scalatest.org/user_guide/using_matchers#matchingAPattern)
+and got bitten by it every time my data model changed slightly.
 
 ## Counter-Examples
 
@@ -60,31 +58,14 @@ This SIP doesn't aim to allow pattern where parameters go into the pattern, e.g:
 val map = Map("Berlin" -> 10, "Paris" -> 5)
 
 map match
-  case Map("Paris" -> five) => five
+  case Map("Paris" = five) => five
 ```
 
-//TODO: find references where this feature was requested
-
 ## Design
 
 Goal is similarity between construction and deconstruction of case classes.
 
-Before this was invalid syntax, so this shouldn't affect any existing Scala program.
-
-### Desugaring
-
-> One important principle of Scala’s pattern matching design is that case classes should be abstractable. I.e. we want to be able to represent the abilities of a case class without exposing the case class itself. That also allows code to evolve from a case class to a regular class or a different case class while maintaining the interface of the old case class. [Martin Odersky](https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829/52)
-
-To create a user defined destructor user the `@names` annotation.
-
-```scala
-class User(val name: String, val age: Int, val city: String)
-
-object User:
-  @names("name", "age", "city")
-  def unapply(user: User): Some[(String, Age, String)] =
-    (user.name, user.age, user.city)
-```
+Up to now this was invalid syntax, so this shouldn't affect any existing Scala program.
 
 ### Mixed usage
 
@@ -93,30 +74,70 @@ But they have no motivational use case. Maybe they should be disallowed.
 
 ```scala
   case User("Anna", city = c) => // Mixed usage seems wired
-  case User(_, city = c) => // Leading underscore are espacially useless
+  case User(_, city = c) => // Leading underscore are especially useless
 ```
 
 ### Disallow same name twice
 
-// TODO: Motivate this restriction
-
 ```scala
   case User(city = city1, city = city2) => a // error city is used twice
   case User(name1, name = name2) => a // error city is used twice
 ```
 
+The same should happen if the `User` had a field with a [deprecated name](https://www.scala-lang.org/api/current/scala/deprecatedName.html).
+
 ### Order of name and term
 
-Normally an equal sign assigns the result of the right side to the left side. With the proposed syntax that's not the case. However, for most, if not all, people that's the correct. The order seems the requires a look ahead in the parser.
+Normally an equal sign assigns the result of the right side to the left side. With the proposed syntax that's not the case. However, for most, if not all, people that's the correct order.
 
-// TODO: Performance test
+This order seems the requires a single look ahead in the parser.
 
-## Implementation
+### Desugaring
+
+> One important principle of Scala’s pattern matching design is that case classes should be abstractable. I.e. we want to be able to represent the abilities of a case class without exposing the case class itself. That also allows code to evolve from a case class to a regular class or a different case class while maintaining the interface of the old case class. [Martin Odersky](https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829/52)
 
+* Allow the same feature of case classes:
+  * Provide arbitrary names
+  * Enable [`@deprecatedName`](https://www.scala-lang.org/api/current/scala/deprecatedName.html), which leads to multiple names for a single field. Using both should be an error.
+* Maybe provide additional named fields. For example for our `User`:
 
-'Simple' rewrite of patterns. If a pattern with a name is encountered, the compiler looks up the index of those names and places the tree accordingly.
+  ```scala
+  case User(ageInDays = 3650) => ...
+  ```
+
+  But this could be an awful feature.
+* Maybe leave fields without names
+
+This SIP proposes basically to use [shapeless records](https://github.com/milessabin/shapeless/wiki/Feature-overview:-shapeless-2.0.0#extensible-records) for the specific purpose of pattern matching.
+For incomplete list of alternatives see [alternative desugaring](#alternative-desugaring) below.
+
+Pro:
+
+* with shapeless records we have a good understanding what we are doing, however we need to tweak the encoding a bit
+* with some helper definitions the usage would be quite short
+* reuse possible
+
+Con:
+
+* opens an can of worms, as this encoding could be useful for other requested features like [named tuples](named-tuple), which would require more thought-out design
+* no support for `@deprecatedName`
+* identifiers are represented with string literals
+
+Example for user:
+
+```scala
+object User:
+  def unapply(user: User): Option[
+    (String, Int, String) & 
+    { type Names = ("name", "age", "city") }
+  ] = (user.name, user.age, user.city).asInstanceOf
+```
+
+The reason to pull the names out, instead of keeping them near to their type, is to prevent extractors to accidentally leaking the name.
 
-// TODO: Brag about the simplicity of the implementation
+## Implementation
+
+'Simple' rewrite of patterns. If a pattern with a name is encountered, the compiler looks up the index of those names and places the tree accordingly.
 
 Example:
 
@@ -134,7 +155,6 @@ case User(
 
 ## Drawbacks
 
-
 ### Allow skipping arguments
 
 Whenever a single named argument is used in pattern, the pattern can have fewer arguments than the unapply.
@@ -144,42 +164,90 @@ This leads to inconsistency, as pointed out by Lionel Parreaux in the [Scala Con
   case User(age = _) => "Just wanted to use the extractor, lol!"
 ```
 
-
 ## Alternatives
 
 ### Without any changes to the language
 
 One alternative way of archiving most objectives, that is doable with current Scala, is to use specialized extractors.
 
 ```scala
-case class User(age: Int)
-
 object User:
   object age:
     def unapply(user: User): Option[Int] =
       Some(user.age)
 
-User(10) match
+user match
   case User.age(y) => y
 ```
 
-Libraries like [Monocle][monocle] could be extended to reduce the boilerplate, but still some boilerplate would remain.
+Libraries like [Monocle][monocle] could be extended to reduce the boilerplate, but some boilerplate would remain.
 In addition, this breaks the intuitive similarity between construction and deconstruction.
 
-### Type as vehicle
+### Alternative desugaring
+
+#### Use underscore methods
+
+In the sprit of https://dotty.epfl.ch/docs/reference/changed-features/pattern-matching.html#name-based-match:
+
+```scala
+object User:
+  class UserMatching(user: User):
+    def _1 = user.name
+    ...
+    
+    def _name = user.name
+    inline def _age = _2
+```
+
+Pro:
+
+* allows to add more fields
+* allows `@deprecatedName`
+
+Con:
+
+* How to detect that a name means the same as a position? Maybe detect simple patterns like the last line in the example?
+* long and verbose, without any shortcuts
 
-But what is with inheritance of the object?
+#### Annotated `unapply` method
+
+```scala
+object User:
+  @names("name", "age", "city")
+  def unapply(user: User): Some[(String, Age, String)] = ...
+```
+
+Pro:
+
+* simple to implement (was done in the first draft implementation)
+
+Con:
+
+* no clear way of encoding deprecated name
+* annotations are not very scalaish
+* no reuse possible
+
+#### Add type as vehicle
 
 ```scala
 object User:
   type Unapply = ("name", "age", "city")
-  def unapply(user: User): Some((String, Age, String)) =
-    (user.name, user.age, user.city)
+  def unapply(user: User): Some((String, Age, String)) = ...
 ```
 
+Pro:
+
+* should be easy to implement
+* the type and the method can inherited from traits and allow some kind of reuse
+
+Con:
+
+* the type and the method can be defined in unrelated traits. Only at the use site of the can be checked if the type and the method agree on the arity of the pattern.
+* no clear way of encoding deprecated name
+
 ### Named Tuple Arguments / Anonymous Case Classes
 
-This was mentioned in the discussion about [Named Tuple Arguments / Anonymous Case Classes][named-tuple] as bonus, that named tuples could transport the names from unapply to the pattern. 
+This was mentioned in the discussion about [Named Tuple Arguments / Anonymous Case Classes][named-tuple] as bonus, that named tuples could transport the names from unapply to the pattern.
 This would be more generic and could handle user defined extractors.
 
 ### Partial destructuring in guards
@@ -191,7 +259,11 @@ Lionel Parreaux proposed a more powerful mechanism, where if guards of cases cou
   case User(age = Age(years)) => years // both cases do the same thing
 ```
 
-His proposal is striclty more powerfull, but arguably less intuitive. Both, Pattern matching with named fields and Partial destructuring in guards could be implemented along each other. Named fields for simple patterns and destructuring in guards for complex patterns. However, they offer two ways to do the same thing and could lead to lots of bike shedding.
+His proposal is strictly more powerful, but arguably less intuitive. Both, Pattern matching with named fields and Partial destructuring in guards could be implemented along each other. Named fields for simple patterns and destructuring in guards for complex patterns. However, they offer two ways to do the same thing and could lead to lots of bike shedding, if both got added to the language.
+
+## Open questions
+
+It could be useful to add extractors with just named fields to sealed traits and enums.
 
 ## References
 
@@ -202,6 +274,6 @@ His proposal is striclty more powerfull, but arguably less intuitive. Both, Patt
 * [Partial Destructuring in Guards][partial-destructuring-in-guards]
 
 [monocle]: https://www.optics.dev/Monocle/ "Monocle"
-[named-tuple]: https://contributors.scala-lang.org/t/named-tuple-arguments-anonymous-case-classes/4352 
+[named-tuple]: https://contributors.scala-lang.org/t/named-tuple-arguments-anonymous-case-classes/4352
 [contributors-thread]: https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829/20 "Scala Contributors thread"
 [partial-destructuring-in-guards]: http://lptk.github.io/programming/2018/12/12/scala-pattern-warts-improvements.html#-partial-destructuring-in-guards