Always treat new-style fors as if enumerators are in braces

With the changes to infix operators this is now a pretty safe choice,
and less surprising than the alternative.

Author: odersky

compiler/src/dotty/tools/dotc/parsing/Parsers.scala

@@ -2011,9 +2011,7 @@ object Parsers {
       val leading = in.token
       val enums =
         if (leading == LBRACE || leading == LPAREN && parensEncloseGenerators) {
-          var enumsOnNewLine = in.isAfterLineEnd() // if true, enums start on new line after `for`, so newlines are significant under Pascal-style syntax
           in.nextToken()
-          enumsOnNewLine |= in.isAfterLineEnd()
           openParens.change(leading, 1)
           val res =
             if (leading == LBRACE || in.token == CASE)
@@ -2034,8 +2032,13 @@ object Parsers {
             val closingOnNewLine = in.isAfterLineEnd()
             accept(leading + 1)
             openParens.change(leading, -1)
-            if (rewriteToNewSyntax(Span(start)) && enumsOnNewLine == (leading == LBRACE)) {
-              // Don't rewrite if that would change meaning of newlines
+            def hasMultiLineEnum =
+              res.exists { t =>
+                val pos = t.sourcePos
+                pos.startLine < pos.endLine
+              }
+            if (rewriteToNewSyntax(Span(start)) && (leading == LBRACE || !hasMultiLineEnum)) {
+              // Don't rewrite if that could change meaning of newlines
               newLinesOpt()
               dropParensOrBraces(start, if (in.token == YIELD || in.token == DO) "" else "do")
             }
@@ -2044,14 +2047,11 @@ object Parsers {
         }
         else {
           wrappedEnums = false
-          val impliedBraces = in.isAfterLineEnd()
 
           /*if (in.token == INDENT) inBracesOrIndented(enumerators()) else*/
-          val ts = // If we use indent syntax, the distinction below should no longer be necessary
-            if (impliedBraces) enumerators()
-            else inSepRegion(LPAREN, RPAREN)(enumerators())
+          val ts = inSepRegion(LBRACE, RBRACE)(enumerators())
           if (rewriteToOldSyntax(Span(start)) && ts.nonEmpty) {
-            if (impliedBraces) {
+            if (ts.length > 1 && ts.head.sourcePos.startLine != ts.last.sourcePos.startLine) {
               patch(source, Span(forEnd), " {")
               patch(source, Span(in.offset), "} ")
             }

docs/docs/reference/changed-features/operators.md

@@ -3,7 +3,8 @@ layout: doc-page
 title: Rules for Operators
 ---
 
-There are two annotations that regulate operators: `infix` and `alpha`.
+The rules for infix operators have changed. There are two annotations that regulate operators: `infix` and `alpha`.
+Furthermore, a syntax change allows infix operators to be written on the left in a multi-line expression.
 
 ## The @alpha Annotation
 
@@ -127,3 +128,53 @@ The purpose of the `@infix` annotation is to achieve consistency across a code b
 
  5. To smooth migration to Scala 3.0, alphanumeric operations will only be deprecated from Scala 3.1 onwards,
 or if the `-strict` option is given in Dotty/Scala 3.
+
+## Syntax Change
+
+Infix operators can now appear at the start of lines in a multi-line expression. Examples:
+```scala
+val str = "hello"
+  ++ " world"
+  ++ "!"
+
+def condition =
+     x > 0
+  || xs.exists(_ > 0)
+  || xs.isEmpty
+```
+Previously, these expressions would have been rejected, since the compiler's semicolon inference
+would have treated the continuations `++ " world"` or `|| xs.isEmpty` as separate statements.
+
+To make this syntax work, the rules are modified to not infer semicolons in front of leading infix operators.
+A _leading infix operator_ is
+ - a symbolic identifier such as `+`, or `approx_==`, or an identifier in backticks,
+ - that starts a new line,
+ - that precedes a token on the same line that can start an expression,
+ - and that is immediately followed by at least one space character `' '`.
+
+Example:
+
+```scala
+    freezing
+  | boiling
+```
+This is recognized as a single infix operation. Compare with:
+```scala
+    freezing
+  !boiling
+```
+This is seen as two statements, `freezing` and `!boiling`. The difference is that only the operator in the first example
+is followed by a space.
+
+Another example:
+```scala
+  println("hello")
+  ???
+  ??? match { case 0 => 1 }
+```
+This code is recognized as three different statements. `???` is syntactically a symbolic identifier, but
+neither of its occurrences is followed by a space and a token that can start an expression.
+
+
+
+

docs/docs/reference/other-new-features/control-syntax.md

@@ -30,22 +30,7 @@ The rules in detail are:
  - Newline characters are not statement separators in a condition of an `if` or a `while`.
    So the meaning of newlines is the same no matter whether parentheses are present
    or absent.
- - Newline characters are statement separators in the enumerators of a `for`-expression if and only if the first generator of the `for` expression appears on a new line.
-
-To illustrate the last rule above, compare
-```scala
-  for x <- xs
-    ++ ys      // newline not significant here
-    ++ zs      // newline not significant here
-  do println(x)
-```
-and
-```scala
-  for
-    x <- xs
-    y <- xs     // newline is significant here
-  do println(x)
-```
+ - Newline characters are potential statement separators in the enumerators of a `for`-expression.
 
 ### Rewrites