Destructuring lambdas #17857
Replies: 0 comments 3 replies
-
Probably a better workaround would be: val f: Pair[Int, Pair[String, Boolean]] => String =
Pair(a, Pair(b, c)) => s"($a, ($b, $c))" But it does have the drawback of requiring a result type. So I like your proposal, because it also seems to make the language more uniform. It would mean that tuple syntax is no longer special. At the very least, I think this should be accepted: val f = { case Pair(x: Int, y: Int) => x } Currently, even this is rejected: val f = { case (x: Int) => x } |
Beta Was this translation helpful? Give feedback.
-
Well that doesn't compile, perhaps you meant val f: Pair[Int, Pair[String, Boolean]] => String =
{ case Pair(a, Pair(b, c)) => s"($a, ($b, $c))" }
Note that destructuring in lambdas is not supported even for tuples: val f = ((a: Int, b: String)) => s"($a, $b)"
I think the convention is that |
Beta Was this translation helpful? Give feedback.
-
Yes, I agree with your points, except the last one. The convention that " |
Beta Was this translation helpful? Give feedback.
-
I propose to support destructuring lambdas, i.e. function definitions in which the parameter is deconstructed via a pattern.
Example:
An important part of this feature is that the pattern would drive type inference:
The type ascriptions
a: Int
,b: String
,c: Boolean
in the pattern above are not type tests; they are constraints for type inference/type checking. The compiler would infer the type off
to bePair[Int, Pair[String, Boolean]] => String
.Workaround
The currently available workaround is to do a destructuring assignment as the first thing in the lambda body:
We can see the repetitiveness as well as the need to introduce an intermediate name
t
.Beta Was this translation helpful? Give feedback.
All reactions