The “sequence of cases” syntax is not a “partial function literal”, it is a “pattern-matching anonymous function”. The pedantic distinction matters because only one of the following is a partial function:
List(42).map:
case i: Int => i + 1
List(42).collect:
case i: Int => i + 1
Function literals yield a function or partial function as required.
I think the use case for “cases in parens” is supported because you get indentation after =>. This is what Haoyi just called “normal” function literals, but which one may call “caseless”.
List(42).map(i =>
val j = i + 1
j + 26
)
This syntax was the basis for arguing against “colon lambda”:
List(42).map: i =>
val j = i + 1
j + 26
Parsing “sequence of cases” in argument parens should be easy. I see that after colon, a subsequent case may be further indented but not dedented, so I’m not sure whether indentation would work the same in parens (whatever the rules are).
List(42).collect:
case i: Int if i < 10 => i + 1
case j: Int if j > 10 => j + 2
Will people still use “parameter untupling” if they can write a case in parens?
In “old” syntax, a function application takes either parens or a block expression, which is why Rex says “it’s just a block”. The paren syntax looks less weird compared to:
List(42).collect:
if b then
case i: Int if i < 10 => i + 1
else
case j: Int if j > 10 => j + 2
I would expect all the one-liners to work, as mentioned on another thread, as well as the multi-case case.
List(42).map: i => i + 1
List(42).map: case i: Int => i + 1
List(42).map(
case i: Int => i + 1
)
List(42).map(i => i + 1)
List(42).map(case i: Int => i + 1)
They took away much-beloved parenless syntax, so it seems a natural progression to add parens and then remove them again:
List(42).map { i: Int => i + 1 } // error now
List(42).map { case i: Int => i + 1 }
List(42).map(case i: Int => i + 1)
List(42).map: case i: Int => i + 1
Syntax for one-line catch (which takes an expression, try 42 catch println(_)) calls it a “case expression” or ExprCaseClause, so I think that is the right lingo.