Desugaring of given in for expressions

[joschua-fink]

Minimized example

import monix.eval.Task

for {
  given Boolean <- Task.now(true)
} yield ()

Output

Without -source 3.1 in Scala 3.0.0-M3

[error] -- [E008] Not Found Error:
[error] 7 |  given Boolean <- Task.now(true)
[error]   |                   ^^^^^^^^^^^^^^
[error]   |value withFilter is not a member of monix.eval.Task[Boolean], but could be made available as an extension method.

With -source 3.1 compiles without any complaint.

Expectation

I'm not sure if this behavior is a bug or an intended side effect of the changes to pattern bindings.

If it is not a bug, I would welcome having it documented clearly. It is hinted to in: https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html but I first looked in https://dotty.epfl.ch/docs/reference/contextual/givens.html and was quite puzzled why it wasn't working, since I wasn't expecting to desugar the above example to a withFilter, when a variant without given was working fine without using withFilter.

[bishabosha]

this comes down to that all given in the context of patterns count as a low priority pattern.
Under 3.0-migration and 3.0 the scala 2 behaviour for for comprehension is maintained for all patterns.
Then from 3.1-migration source mode and later the scala 2 behaviour is dropped in favour of the irrefutable match variant that drops withFilter (unless you use case in front of the pattern). I believe that this section is the clearest explanation https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html#migration

[joschua-fink]

@bishabosha Thank you for writing it more clearly than I could. This behavior makes sense from this perspective, I got that.

The thing is given in for comprehensions is a new feature. As I understand there is no way to use it in 3.0 in situations where there is no withFilter is provided (like in monix.eval.Task). So in 3.0 I have to use:

import monix.eval.Task

def foo()(using Boolean): Task[Unit] = ???

for {
  b <- Task.now(true)
  _ <- foo()(using b)
} yield ()

where I can write in 3.1:

import monix.eval.Task

def foo()(using Boolean): Task[Unit] = ???

for {
  given Boolean <- Task.now(true)
  _ <- foo()
} yield ()

For me personally it isn't really an issue since I'm anyway trying to work with 3.1. But I expect that I will not be the only one being confused by this behavior. Since given doesn't really imply that there is any pattern matching/filtering/type casting/... needed.

[bishabosha]

Perhaps we can reframe this issue as the feature request "given patterns could behave like wildcard/identifier typetest patterns" - that makes most sense to me given your concern,

[bishabosha]

or perhaps it is a bug that it always generates a de-structuring step even if the types are irrefutable

[odersky]

Closed by #12184