For now we’ll go with the nesting. If there are strong concerns, it would be trivial to disallow it.
The proposal now also covers this case, discovered by @prolativ:
fun: (x: Int) => (y: Int) =>
x + y
That is currently disallowed, but will be allowed under the proposal.
Out of curiosity, how would this compare to $/& from Haskell or to <|/|> from F#?
Those are functions and this is not, but otherwise this looks similar. Or am I missing something?
I wonder if it would be possible to support cases when there are some statements inside the outer lambda before it returns the inner one, e.g.:
fun { (x: Int) =>
val a = 123
{ (y: Int) =>
x + y + a
}
}
What could it look like in the fully brace-free style?
fun: (x: Int) =>
val a = 123
(y: Int) =>
x + y + a
That’s already possible today, without the Pre-SIP.
3 posts were split to a new topic: Should we gather usage statistics about SIP-44 (fewer braces)?
What are the concerns with this Pre-SIP in the first place? I can understand that some people may or may not like the braceless syntax in general, but if we assume that ship has sailed, I believe that this Pre-SIP makes a nice addition to the braceless syntax regardless:
data
.map: x => x * 2
.filter: x => x % 3 != 0
.flatMap: x => Seq(x, x + 1)
.collect: case x if x < 8 => s"Val:$x"
We could argue whether it would look better with braces or not, but I believe it is hard to argue that, in the braceless universe, it is significantly better than without this Pre-SIP:
data
.map: x =>
x * 2
.filter: x =>
x % 3 != 0
.flatMap: x =>
Seq(x, x + 1)
.collect:
case x if x < 8 => s"Val:$x"
Or am I missing some caveats?
I wonder though if it would be possible to make the placeholder syntax braceless too, e.g.:
data
.map: _ * 2
.filter: _ % 3 != 0
Maybe it is not worth it, just being curious.
For me the main concern is that the “braceless” syntax was sold as “significant indentation, with optional braces”. I.e. all programs are supposed to be well-indented and consequently braces can be inferred so you can optionally leave them out, just like you can leave out ; if a program is well-newlined.
Yet in the examples you present here we don’t need any quirky additional syntax (except for the partial function, but IMO it’s the fact that single-case PFs require braces—which has always been kind of arbitrary—that should be tackled here).
This is perfectly functioning braceless scala 3 code:
data
.map(x => x * 2)
.filter(x => x % 3 != 0)
.flatMap(x => Seq(x, x + 1))
data
.map(x =>
println(x)
x * 2
)
.filter(x =>
println(x)
x % 3 != 0
)
.flatMap(x =>
println(x)
Seq(x, x + 1)
)
It’s a good proposal, and continues in the spirit of whitespace notation. Those who were fans of the new whitespace notation are likely to support the proposal, and those who were against it and prefer braces are more likely to come up with exaggerated complaints, as it continues in the direction they didn’t want.
The exceptional case of short lambdas is the point of this proposal. The point is consistency. Yes, the majority of lambdas are involved enough that they read better by indenting across lines, and in those cases, we prefer the braceless notation to solve the problem of ugly close-parens. But it is not rare that we also write lambdas that are simple enough to read best as a single line, and since we have already settled on the braceless notation for the majority cases, we should also allow braceless notation in the minority case, for the virtue of consistency.
It’s better to not mix styles in a single codebase. Parentheses do look fine, but so would braceless (without newline), and in a codebase that has gone all in on braceless notation, it is are an inconsistency. If a proposed syntax feels more consistent with other syntax and style in the language, that is inherently compelling, and an improvement. I think rather than people saying that they don’t find it “compelling enough”, they need to articulate what disadvantages they think outweigh this advantage of consistency, otherwise we should go forward with it by default as it is at the very least a slight improvement.
As a personal data point, when I discovered the braceless notation for lambdas, I soon tried to use it for a simple single line lambda expecting it to work, and I was disappointed to find it doesn’t. To most users, it does feel arbitrary to require a newline, and is irritating enough to convince them to resort to using parentheses to avoid taking up multiple lines, now creating notational inconsistency in their codebase.
I forgot to announce before, and was only reminded by the recent activity on this thread: Single-line lambdas and case expressions in parentheses were both accepted for experimental implementation at the October SIP meeting. They are available under the language.experimental.relaxedLambda syntax in Scala 3.8 (currently as nightlies to be released as RC1 soon).
We discussed this on our SIP-meeting yesterday and it would be great if we all here can help spread that this is available as experimental. If you try it out, any feedback is welcome here as input to the SIP-committee when we eventually vote for its next step.
You can try it with the latest Install Scala CLI | Scala CLI version 1.10.1 like so:
> scala-cli repl -S 3.nightly
Welcome to Scala 3.8.1-RC1-bin-20251129-7eab684-NIGHTLY-git-7eab684 (21.0.6, Java OpenJDK 64-Bit Server VM)..8 KiB (1.2 MiB / s)
Type in expressions for evaluation. Or try :help.
scala> import language.experimental.relaxedLambdaSyntax
scala> Seq(1,2,3).map: x => x + 1
val res1: Seq[Int] = List(2, 3, 4)
I am curious how we’ll be able to distinguish between
fun { x: Int => <fun_body> } // parens weren't necessary around param within {}
and
fun1 { fun2: x => x + 1 }
The first syntax is not allowed in Scala 3:
scala> fun { x: Int => <fun_body> }
-- Error: ----------------------------------------------------------------------
1 |fun { x: Int => <fun_body> }
| ^
| parentheses are required around the parameter of a lambda
And it would not be allowed in the new proposal either, since the lambda does not end with the newline - there’s a closing brace instead.