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
* a `getOrElse` method for a heterogeneous key-value store, which is an occurrence of wanting a type parameter whose bounds are path-dependent on a term parameter, and
36
-
37
-
### Heterogeneous key-value store
38
33
Consider an API for a heterogenous key-value store, where keys know what type of value they must be associated to:
39
34
~~~scala
40
35
traitKey:
@@ -83,7 +78,6 @@ While again, this provides the expected API at call site, it also has issues:
83
78
* The behavior is not the same, as `default` has to be a by-value parameter
84
79
* The definition is hard to visually parse, as users are more used to methods (and it is our opinion this should remain so)
85
80
* The definition is cumbersome to write, especially if there are a lot of term parameters
86
-
* Methods containing curried type clauses like `def foo[A][B](x: B)` cannot be represented in this way, as polymorphic methods always have to have a term parameter right after.
87
81
* It is inefficient, as many closures must be created for each call to `getOrElse` (one per term clause to the right of the first non-initial type clause).
The main rules of interest are `DefParamClauses` and `DefParamClauseChunk`, which now allow any number of type parameter clauses, term parameter clauses and using parameter clauses, in any order as long as there are no two adjacent type clauses.
125
119
126
-
Note that these are also used for the right-hand side of extension methods, clause interleaving thus also applies to them.
120
+
Note that these are also used for the right-hand side of extension methods, thus clause interleaving also applies to them.
127
121
128
122
It is worth pointing out that there can still only be at most one implicit parameter clause, which, if present, must be at the end.
0 commit comments