Scala 3 regression of new-line braced block argument

[soronpo]

The following code works in Scala 2.13. In Scala 3 the braces {} (when appearing in a new line) are considered to be separate from the method call.

Compiler version

v3.2.2-RC2

Minimized code

https://scastie.scala-lang.org/UUJ5id94STydaoPDCkAQhQ

@main def main: Unit =
  def process(arg: Int)(block: => Unit): Int = arg
  val x = process(1) 
  {
  }
  println(x)

Output

warning:   A pure expression does nothing in statement position; you may be omitting necessary parentheses
main$package$$$Lambda$26822/0x00000008049bcc10@4f7a0b91

Expectation

Should print 1.

[soronpo]

I'm actually very surprised we didn't stumble upon this beforehand. I checked and it's the same all the way back to 3.0.0.

[odersky]

This is actually fully intentional because it solves a nasty problem with Scala 2:

println(x)
{ val y = ...
  println(y)
}

does not do what you think it should do in Scala 2. In Scala 3, a block or parenthesized expression on the next line is only treated as a continuation of the previous line if it is indented.

[soronpo]

But what about this code (the actual original code the led me to post this issue).
Doesn't work, and very common to see this style of braces in the wild:

process(arg)
{
//code
}

Works:

process(arg) {
//code
}

I claim that since both our arguments are valid, the fact that mine preserves the Scala 2 behavior, and is more likely to appear, we should switch the behavior back to prevent such regressions.

[soronpo]

Additionally, your long term goal for the language is to be braceless anyways, so there is no reason to break existing braced syntax.

[odersky]

Additionally, your long term goal for the language is to be braceless anyways, so there is no reason to break existing braced syntax.

That's a good point.

I am not sure how common the pattern with opening brace on the left is. The fact that nobody noticed the change so so far indicates that it might not be very common. Also, if we can keep ruling out this pattern then we avoid the common gotcha where a block after an application is not recognized.

I have opened in #16767 a draft PR to revert to the Scala 2 rules. Some tests broke as well one instance in the compiler, where a brace opening a follow-on block was used without a preceding newline. So adopting #16767 will technically be a regression on previous Scala 3 rules.

So, not sure what to do here. @tgodzik What is your take on this?

[soronpo]

I have opened in #16767 a draft PR to revert to the Scala 2 rules. Some tests broke as well one instance in the compiler, where a brace opening a follow-on block was used without a preceding newline. So adopting #16767 will technically be a regression on previous Scala 3 rules.

Maybe we should raise this point for a short vote for the next SIP meeting. Kind of choosing what we should break. I don't know if this particular issue was raised during the SIP talks confirming the Scala 3 syntax.

[tgodzik]

@main def main: Unit =
  def process(arg: Int)(block: => Unit): Int = arg
  val x = process(1) 
  {
  }
  println(x)

Scalameta currently parses the same way as the compiler, so only indented { will be counted as belonging to the previous expression. I think this is a much better behaviour IMHO, since it might unexpected that the next block is being taking into previous expression. On the plus side, if someone uses scalafmt they will most likely see what is going since this will be autoformatted differently whichever solution we decide on.

We can change that in Scalameta, but should we keep it as is for the version prior to the one this will be merged to?

Also, if no one raised that until then, is it a problem to keep the current behaviour? What about parenthesis? For example:

process(arg)
(code)

would that be also treated as the same expression and if not isn't it a bit inconsistent?

[odersky]

Parentheses will not be seen as a continuation. So yes, the Scala 3 behavior is more consistent. And if it did not cause problems yet, we might as well stick with it.