SIP-44 - Fewer braces

[odersky]

No description provided.

[gabro]

I've read the proposal and (tried to) read all the related discussions on the contributors forum.

I've written Scala for 10 years, and I haven't had a chance to write a lot of code with the new indentation style, so I still have mixed feelings about the whole thing.

That said, taking optional braces as they are today as a starting point, I agree they would feel unfinished without this last bit of syntax, so I'm overall ✅ on this proposal.

One thing that came out during the contributors discussion is how this would look in case of multiple block parameters, like with groupMap or groupMapReduce from the standard library.

@odersky, since I don't see it mentioned in the proposal document here, nor in the documentation, what's the recommended syntax for handling multiple block parameters? Or in that case we would still recommend braces?

Either way, I think it would make sense to mention that case in the proposal.

[sjrd]

I've not been assigned to this SIP, but I had already done quite a bit of "reviewing" back in May. So I'll just link to the main post where I laid down my findings:
https://contributors.scala-lang.org/t/make-fewerbraces-available-outside-snapshot-releases/5024/23?u=sjrd

[odersky]

Note that the discussion in https://contributors.scala-lang.org/t/make-fewerbraces-available-outside-snapshot-releases/5024/23?u=sjrd was about a previous proposal which did not use : in front of lambda parameters.

[odersky]

@gabro For multiple block parameters I would propose what I proposed in this comment on the long contributors thread:

https://contributors.scala-lang.org/t/make-fewerbraces-available-outside-snapshot-releases/5024/167?u=odersky

I'll update the draft with that content.

[julienrf]

I would like to add here a comment that I wrote there: the proximity with type ascriptions makes code harder to read.

trait X:
  type Y
  def Y: Y

def f(n: Int): (x: X) => x.Y
f(42): ((x: X) => x.Y) // This is not a lambda but a type ascription

Even without involving dependent function types, the proximity between brace-less lambdas and function types is quite close:

// lambda
xs.map: x =>
  x + 1

// type ascription
xs.f: (Int => Int)

[odersky]

=> is already heavily overloaded in Scala syntax. In practice, a simple way to visually distinguish a lambda argument from a type ascription will be that the lambda argument ends with a => at the end of the line. Yes, you can fool the logic by putting parentheses around it, as in:

  val y = xs.map: ((x: Int) =>
    Int)

But I think this will be done very rarely, and we can suggest it should be avoided. (I.e. if you write a multi-line function type, put the =>s in front rather at the end of lines.) So then the problem that remains is that if you intentionally write confusing layout and you read only superficially then things can be confusing. But that's really nothing out of the ordinary.

[julienrf]

Do you mind elaborating on the drawbacks of the status quo? Why is this an important problem?

Also, the brace-less syntax can be used with function arguments:

xs.map(x =>
  val y = x - 1
  y * y
)

This was not possible in Scala 2.

[odersky]

Yes, but that does not work in all cases, which is why I would recommend to stick to braces. E.g.

times(10)(
  val x = ...
  x * x
)

does not work.

[odersky]

@gabro @julienrf I worked in your suggestions in the proposal.

[chrisandrews-ms]

Sorry, I'm rather late to the party. I've read through the contributors thread, and it seems to me that all of the reasonable queries have been dealt with in the revised proposal. I'm on the fence about braceless syntax in general, but this proposal seems to be an important enhancement without significant drawbacks, so I'm in favor.

[gabro]

I agree, and I recommend accepting this proposal at the next SIP meeting.

[dragos]

I echo @gabro's review. This looks like a good addition to the current indentation-based syntax and I don't see any drawbacks.

[chrisandrews-ms]

The outcome of the vote at the 26 August SIP Committee meeting was to accept the proposal as an experimental feature. In fact it is already an experimental feature (which predates the current process), but the vote has formalized that status.

Some concerns were raised about ugly syntactic edge cases but it was pointed out that braces and parentheses remain available even when this feature is enabled.

It was also highlighted that colons are in fact not used by control keywords, e.g.

if x < 0 then -x else x

while x >= 0 do x = f(x)

for x <- xs if x > 0
yield x * x

So this proposal still doesn't allow methods with by-name parameters to be invoked in a way that looks exactly like control syntax, but that wasn't considered a blocker for this proposal.

[benhutchison]

Just wanted to report back with some positive feedback and appreciation ❤️ for this feature, based on a couple of months now of writing Scala 3.3.x in braceless style. I'm really enjoying it 😁! My brain quickly adapted as indentation was already the key cue for block structure. For me, Scala has got unambiguously better by leaving the braces behind.