Skip to content

Commit e608797

Browse files
committed
Improve references and spelling
1 parent 3148b6f commit e608797

File tree

1 file changed

+25
-18
lines changed

1 file changed

+25
-18
lines changed

_sips/sips/2021-06-25-pattern-matching-with-named-fields.md

Lines changed: 25 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -36,6 +36,8 @@ The Deconstruction allows the same syntax as the construction and seems to be wh
3636

3737
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:
3838

39+
//TODO: how offend does this pattern occur?
40+
3941
```scala
4042
val annasCity = user match
4143
case User("Anna", _, c) => c
@@ -46,7 +48,8 @@ val annasCity = user match
4648

4749
This makes it hard which parameter means what, basically the same idea as for named arguments. (The IDE can help here)
4850

49-
In addition, it breaks every time a field of `User` gets added, rearranged, or removed. In the worst case it breaks silently, if to fields with the type switch places.
51+
In addition, it breaks every time a field of `User` gets added, rearranged, or removed.
52+
In the worst case it breaks silently, if two fields with the type switch places.
5053

5154
Personal motivation comes from using to offend https://www.scalatest.org/user_guide/using_matchers#matchingAPattern
5255
and got bitten every time the data model changed slightly.
@@ -63,31 +66,29 @@ map match {
6366
}
6467

6568
4 match {
66-
case n / 2 => "douple of " + n.toString
69+
case n / 2 => "double of " + n.toString
6770
case _ => "odd"
6871
}
6972
```
7073

71-
//TODO: find references where is feature was requested
74+
//TODO: find references where this feature was requested
7275

7376
## Design
7477

7578
Goal is similarity between construction and deconstruction of case classes.
7679

7780
Before this was invalid syntax, so this shouldn't affect any existing Scala program.
7881

79-
### Open questions
82+
### Mixed usage
8083

81-
Various patterns are allowed to keep the similarity, but have no motivational use case. Maybe those should be allowed:
84+
Mixed patterns are allowed to keep the similarity, but have right now no motivational use case. Maybe those should be allowed:
8285

8386
```scala
8487
case User("Anna", city = c) => // Mixed usage seems wired
8588
case User(_, city = c) => // Leading underscore are espacially to useless (?)
8689
```
8790

88-
Discuss design decisions (including, as examples):
89-
90-
* What's with user defined `unapply` on case classes? (Design)
91+
//TODO: What's with user defined `unapply` on case classes? (Design)
9192

9293
## Implementation
9394

@@ -108,7 +109,6 @@ case User(
108109
)
109110
```
110111

111-
112112
## Drawbacks
113113

114114
Without allowing user defined named arguments in pattern matching, the fact that class is a case class becomes part if it's public interface. Changing a case class to a normal class is a backward incompatible change, that library maintainers of to be aware. This is especially worrying since currently libraries where designed without this feature in mind.
@@ -146,22 +146,29 @@ User(10) match {
146146
}
147147
```
148148

149-
Libraries like [Monocle][2] could be extended to reduce the boilerplate, but still some boilerplate would remain.
149+
Libraries like [Monocle][monocle] could be extended to reduce the boilerplate, but still some boilerplate would remain.
150150
In addition, this breaks the intuitive similarity between construction and deconstruction.
151151

152-
### Records, Tuples with names etc.
152+
### Named Tuple Arguments / Anonymous Case Classes
153153

154-
//TODO
154+
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.
155+
This would be more generic and could handle user defined extractors.
155156

156-
Would be more generic, could be handle user defined extractors, also could lead naturally to a way to hand;e Counter-Example above.
157+
However this isn't much of an alternative, but more of a generalization.
157158

158-
### Partial destructuring
159+
### Partial destructuring in guards
159160

160161
Lionel Parreaux proposed a more powerful mechanism:
161162
http://lptk.github.io/programming/2018/12/12/scala-pattern-warts-improvements.html#-partial-destructuring-in-guards
162163

163-
If this SIP gets accepted, it could restrict the design any of the last two alternatives, if they come into being.
164164

165-
[2]: https://www.optics.dev/Monocle/ "Monocle"
166-
[4]: https://github.com/dogescript/dogescript "Alternatives"
167-
[5]: https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829/20 "Scala Contributors thread"
165+
## References
166+
167+
* [Scala Contributors Thread][contributors-thread]
168+
169+
* [Monocle][monocle]
170+
* [Named Tuple Arguments / Anonymous Case Classes][named-tuple]
171+
172+
[monocle]: https://www.optics.dev/Monocle/ "Monocle"
173+
[named-tuple]: https://contributors.scala-lang.org/t/named-tuple-arguments-anonymous-case-classes/4352
174+
[contributors-thread]: https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829/20 "Scala Contributors thread"

0 commit comments

Comments
 (0)