Clarification of intended ’if … then’ new control syntax interaction with newlines

[djneades]

Compiler version

3.0.0

Minimized code

This compiles:

val x = Some(10)

def f =
   if x.exists(x => x == 10) then
      println("Yes")
   else
      println("No")

But this does not:

val x = Some(10)

def f =
   if x.exists
        (x => x == 10) then
      println("Yes")
   else
      println("No")

Expectation

Given that Scala 3 allows method calls like this in other contexts:

foo
  (arg)

the if x.exists … in the second example above seems at least intuitively plausible, even though it doesn’t compile. Clarification as to whether or not that latter example should be considered valid would be appreciated. (The New Control Syntax page doesn’t obviously settle the matter.)

My doubt here arises from:

1. whether the newline after the if x.exists should terminate the if condition, as it currently seems to do in Scala 3.0.0;

2. or whether the if condition should instead be considered to continue up until the following then, the newline before the indented argument to x.exists being treated as it would be in other contexts.

Interestingly, this does compile:

val x = Some(10)

def f =
   if
      x.exists
         (x => x == 10) then
      println("Yes")
   else
      println("No")

As does:

val x = Some(10)

def f =
   if
      x.exists
         (x => x == 10)
   then
      println("Yes")
   else
      println("No")

Note that this question arose in this Scalafmt-related comment.

[djneades]

(Description edited.)

[som-snytt]

This is analogous to for ( ... ) vs for { ... }, where analogous means just the same.

"Braced" or "block" behavior, but with the braces optional, needs an indent:

def f =
   if
      x.exists
        (_ == 10)
   then
      "Yes"
   else
      "No"

Otherwise, the if conditional will keep hoovering up an ordinary expression that continues on the next line, whether or not it started with a paren:

def p =
   if 1
      +
      2
      <
      4 then
      42
   else
      17

def q =
   if (1 + 2)
      <
      4 then
      42
   else
      17

The potential for ambiguity:

   if (1 + 2 < 4)
      (true)         // normal "is it a continued line" rules apply
   then

There is an intuition that it should take up to the then, as it does for case:

def k =
   x match
      case Some(y) =>
         x.exists
            (_ == y)
      case _ =>
         false

Usual example where we need to add grouping parens:

def g = (
   x.exists
        (_ == 10)
)

I don't remember if they plan to keep traditional paren syntax; if quiet syntax becomes standard, then they can vacuum to the next then, which would be required.

Footnote: I tried out 3-space indents here! but frankly, with top-level defs, I don't really indent much any more.

[tgodzik]

This one is pretty weird:

def f =
   if
      x.exists
         (x => x == 10) then
      println("Yes")
   else
      println("No")

and if can start and indented block, which seems to be the case in this place, but then should be an error here.

[som-snytt]

There is the (provisional) rule for "parsing of legacy code with ad-hoc layout." https://dotty.epfl.ch/docs/reference/other-new-features/indentation.html