Skip to content

Commit d240fb8

Browse files
committed
Discuss alternative syntax for case arguments
1 parent 4584bbe commit d240fb8

File tree

1 file changed

+11
-1
lines changed

1 file changed

+11
-1
lines changed

content/fewer-braces.md

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,7 @@ title: SIP-NN Fewer Braces
1414
|----------------|--------------------|
1515
| July 1st 2022 | Initial Draft |
1616
| July 21st 2022 | Expanded Other Conerns Section |
17+
1718
## Summary
1819

1920
The current state of Scala 3 makes braces optional around blocks and template definitions (i.e. bodies of classes, objects, traits, enums, or givens). This SIP proposes to allow optional braces also for function arguments.
@@ -172,7 +173,7 @@ xs.groupMapReduce: item =>
172173

173174
I argue that the language already provides mechanisms to express these examples without having to resort to braces. (Aside: I don't think that resorting to braces occasionally is a bad thing, but some people argue that it is, so it's good to have alternatives). Basically, we have three options
174175

175-
- Use parentheses. That always works if the argument is a lambda.
176+
- Use parentheses.
176177
- Use an explicit `apply` method call.
177178
- Use a `locally` call.
178179

@@ -273,6 +274,15 @@ val y = (xs.map: (Int => Int) =>
273274
```
274275
would then not be legal anyway. But it turned out that there were several community projects that were using function types in ascriptions without enclosing parentheses, so this change was deemed to break too much code.
275276

277+
@sjrd proposed in a [feature request](https://github.com/lampepfl/dotty-feature-requests/issues/299) that the `:` could be left out when
278+
followed by `case` on the next line. Example:
279+
```scala
280+
val xs = List((1, "hello"), (true, "bar"), (false, "foo"))
281+
val ys = xs.collect // note: no ':' here
282+
case (b: Boolean, s) if b => s
283+
println(ys)
284+
```
285+
This is a tradeoff between conciseness and consistency. In the interest of minimality, I would leave it out of the first version of the implementation. We can always add it later if we feel a need for it.
276286

277287
## Related work
278288

0 commit comments

Comments
 (0)