In 3.4 make refutable patterns in a for comprehension an error

[bishabosha]

supersedes #16665

Only make refutable patterns in a for comprehension an error, here we have a clear set in stone solution: put case before the pattern.

It is still in the air the ideal solution for pattern val definitions, see https://contributors.scala-lang.org/t/pre-sip-replace-non-sensical-unchecked-annotations/6342/85, so keep those as a warning for now

Release notes

In 3.4 refutable patterns (i.e. patterns that might not match) in a for-comprehension generator must now be preceded by case, or else an error is reported.

e.g.

val xss = List(List(1, 2), List(3))

for y :: ys <- xss do println(y > 1)
//  ^^^^^^^
// error: pattern's type ::[Int] is more specialized than the right hand
// side expression's type List[Int]
// 
// If the narrowing is intentional, this can be communicated by adding
// the `case` keyword before the full pattern, which will result in a filtering
// for expression (using `withFilter`).

.withFilter is also no longer inserted for a pattern in a generator unless prefixed by case, meaning improved ergonomics for many types that do not implement .withFilter

[carlosedp]

Do this PR supports the direct tuple assignment in a for comprehension?

[bishabosha]

Do this PR supports the direct tuple assignment in a for comprehension?

not sure quite what you mean, but e.g.

for (a, b) <- ((1 to 10) zip ('a' to 'z'))
yield s"$a$b"

will desugar to

((1 to 10) zip ('a' to 'z'))
  .map((a, b) => s"$a$b")

instead of

((1 to 10) zip ('a' to 'z'))
  .withFilter({ case (a, b) => true; case _ => false })
  .map((a, b) => s"$a$b")

[sjrd]

Why did these error messages move? It seems non-optimal, as the messages are not in source order anymore.

[bishabosha]

all that was changed was the warning became an error, so perhaps under -Werror true errors print last?

[carlosedp]

I mean, with this we could write:

  def z = for
      (a, b) <- ZIO.fromOption(Some(1, 2))
    yield (a, b)

Like the behavior with "-source:future" instead of assigning the result first to a variable and then unpack the tuple:

  def y = for
      x <- ZIO.fromOption(Some(1, 2))
      (a, b) = x
    yield (a, b)

[bishabosha]

I mean, with this we could write:

  def z = for
      (a, b) <- ZIO.fromOption(Some(1, 2))
    yield (a, b)

Like the behavior with "-source:future" instead of assigning the result first to a variable and then unpack the tuple:

  def y = for
      x <- ZIO.fromOption(Some(1, 2))
      (a, b) = x
    yield (a, b)

yes this PR makes the pattern checking for comprehensions behave like -source:future, but now its with -source:3.4 (or newer)