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
An readable, extendible, and intuitive way to deconstruct case classes in pattern matching.
17
+
An readable, extensible, and intuitive way to deconstruct case classes in pattern matching.
18
18
19
19
Link to work in progress implementation lives here: https://github.com/Jentsch/dotty
20
20
@@ -137,28 +137,32 @@ The reason to pull the names out, instead of keeping them near to their type, is
137
137
138
138
## Implementation
139
139
140
-
'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.
140
+
If a pattern with a name is encountered, the compiler looks up list of provided names and places the trees accordingly.
141
+
142
+
The list of names either provided by the return type of the unapply method or by the constructor list of the case class.
141
143
142
144
Example:
143
145
144
146
```scala
145
147
// a match clause like
146
-
caseUser(age = <tree>) =>???
148
+
caseUser(<tree1>, city = <tree2>) =>???
147
149
148
150
// gets rewritten to:
149
151
caseUser(
152
+
<tree1>, // because tree1 is positional pattern
150
153
_, // because name isn't mentioned
151
-
<tree>, // because age is the second parameter of user
152
-
_ // because city isn't mentioned
154
+
<tree2>, // because city is the third parameter of user
153
155
)
154
156
```
155
157
158
+
This allows us to glace over the details of how pattern matching gets desugared further down the line.
159
+
156
160
## Drawbacks
157
161
158
162
### Allow skipping arguments
159
163
160
-
Whenever a single named argument is used in pattern, the pattern can have fewer arguments than the unapply.
161
-
This leads to inconsistency, as pointed out by Lionel Parreaux in the [Scala Contributors Thread](https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829/44). This could lead users to use a named pattern, just to skip all parameters.
164
+
Whenever a single named argument is used in pattern, the pattern can have fewer arguments than the unapply provides. This is driven by the motivation the make pattern matching extensible.
165
+
But this leads to (arguably small) inconsistency, as pointed out by Lionel Parreaux in the [Scala Contributors Thread](https://contributors.scala-lang.org/t/pattern-matching-with-named-fields/1829/44). This could lead users to use a named pattern, just to skip all parameters.
162
166
163
167
```scala
164
168
caseUser(age = _) =>"Just wanted to use the extractor, lol!"
@@ -185,9 +189,11 @@ In addition, this breaks the intuitive similarity between construction and decon
185
189
186
190
### Alternative desugaring
187
191
192
+
As the above described desugaring has its drawbacks.Here are some alternatives with other drawbacks, and maybe better trade-offs.
193
+
188
194
#### Use underscore methods
189
195
190
-
In the sprit of https://dotty.epfl.ch/docs/reference/changed-features/pattern-matching.html#name-based-match:
196
+
In the sprit of [name based pattern matching](https://dotty.epfl.ch/docs/reference/changed-features/pattern-matching.html#name-based-match):
191
197
192
198
```scala
193
199
objectUser:
@@ -203,11 +209,13 @@ Pro:
203
209
204
210
* allows to add more fields
205
211
* allows `@deprecatedName`
212
+
* is the only desugaring, that doesn't use string literals
206
213
207
214
Con:
208
215
209
216
* How to detect that a name means the same as a position? Maybe detect simple patterns like the last line in the example?
210
-
* long and verbose, without any shortcuts
217
+
* long and verbose, without any shortcuts in sight
218
+
* An underscore at the beginning of a name is an unheard of pattern, even in Scala. This could accidentally expose fields, which weren't suppose to become fields.
211
219
212
220
#### Annotated `unapply` method
213
221
@@ -255,7 +263,7 @@ This would be more generic and could handle user defined extractors.
255
263
Lionel Parreaux proposed a more powerful mechanism, where if guards of cases could them self contains destructuring patterns.
256
264
257
265
```scala
258
-
caseuser: UserifAge(years) <- user => years
266
+
caseuser: UserifAge(years) <- user.age=> years
259
267
caseUser(age =Age(years)) => years // both cases do the same thing
260
268
```
261
269
@@ -265,6 +273,8 @@ His proposal is strictly more powerful, but arguably less intuitive. Both, Patte
265
273
266
274
It could be useful to add extractors with just named fields to sealed traits and enums.
267
275
276
+
What would reuse would look like? What is desirable?
0 commit comments