You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _sips/sips/2021-06-25-pattern-matching-with-named-fields.md
+25-18Lines changed: 25 additions & 18 deletions
Original file line number
Diff line number
Diff line change
@@ -36,6 +36,8 @@ The Deconstruction allows the same syntax as the construction and seems to be wh
36
36
37
37
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:
38
38
39
+
//TODO: how offend does this pattern occur?
40
+
39
41
```scala
40
42
valannasCity= user match
41
43
caseUser("Anna", _, c) => c
@@ -46,7 +48,8 @@ val annasCity = user match
46
48
47
49
This makes it hard which parameter means what, basically the same idea as for named arguments. (The IDE can help here)
48
50
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.
50
53
51
54
Personal motivation comes from using to offend https://www.scalatest.org/user_guide/using_matchers#matchingAPattern
52
55
and got bitten every time the data model changed slightly.
@@ -63,31 +66,29 @@ map match {
63
66
}
64
67
65
68
4match {
66
-
case n /2=>"douple of "+ n.toString
69
+
case n /2=>"double of "+ n.toString
67
70
case _ =>"odd"
68
71
}
69
72
```
70
73
71
-
//TODO: find references where is feature was requested
74
+
//TODO: find references where this feature was requested
72
75
73
76
## Design
74
77
75
78
Goal is similarity between construction and deconstruction of case classes.
76
79
77
80
Before this was invalid syntax, so this shouldn't affect any existing Scala program.
78
81
79
-
### Open questions
82
+
### Mixed usage
80
83
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:
82
85
83
86
```scala
84
87
caseUser("Anna", city = c) =>// Mixed usage seems wired
85
88
caseUser(_, city = c) =>// Leading underscore are espacially to useless (?)
86
89
```
87
90
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)
91
92
92
93
## Implementation
93
94
@@ -108,7 +109,6 @@ case User(
108
109
)
109
110
```
110
111
111
-
112
112
## Drawbacks
113
113
114
114
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 {
146
146
}
147
147
```
148
148
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.
150
150
In addition, this breaks the intuitive similarity between construction and deconstruction.
151
151
152
-
### Records, Tuples with names etc.
152
+
### Named Tuple Arguments / Anonymous Case Classes
153
153
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.
155
156
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.
157
158
158
-
### Partial destructuring
159
+
### Partial destructuring in guards
159
160
160
161
Lionel Parreaux proposed a more powerful mechanism:
0 commit comments