Pattern given on the LHS of a val definition should enter corresponding scope

[LPTK]

Compiler version

3.0.0-RC1

Minimized code

scala> given Int = 0
lazy val given_Int: Int

scala> def test = {
     |   val (x, given Int) = (1, 1)
     |   summon[Int]
     | }
def test: Int

scala> test                                                                                                             
val res0: Int = 0

Expectation

This is quite surprising/unexpected.

I would expect it to work in the same way as the following:

scala> def test = {
     |   given Int = 1
     |   summon[Int]
     | }
def test: Int

scala> test
val res1: Int = 1

[bishabosha]

def test = {
  val (x, given Int) = (1, 1)
  summon[Int]
}

desugars to the following:

def test: <error no implicit values were found that match type Int> = 
  {
    val x: Int =
      Tuple2.apply[Int, Int](1, 1):(Int, Int) @unchecked match 
        {
          case Tuple2.unapply[Int, Int](x @ _, given given_Int @ _:Int) =>
            x:Int
        }
    summon[Int](/* missing */summon[Int])
  }

[LPTK]

Yes, but that's totally unexpected from a user point of view.

I always thought the desugaring of local val bindings with patterns was unnecessarily convoluted and allocation-heavy.

The correct approach would be to desugar them as:

def test = {
  (1, 1) match
  case (x, given Int) =>
    summon[Int]
    ... // rest of the block
}

Though this does not really generalize to member vals, which I am not convinced should be allowed to bind patterns anyway.

[bishabosha]

sorry I should clarify, I agree that alongside x there should be introduced a definition for the given if the current design continues

[odersky]

Though this does not really generalize to member vals, which I am not convinced should be allowed to bind patterns anyway.

Note: this would also mean that toplevel vals and object vals cannot be allowed to bind patterns. So a rather drastic change.

[LPTK]

Yes, it would definitely be too drastic to disallow them now. So at least member vals have to be supported with the current scheme (which still needs to be improved to handle given patterns).
But that doesn't prevent using a more efficient scheme for local vals.

BTW, the problem in this issue is reminiscent of the limitations of type binding in val definitions. For instance:

val (ls: List[t]) = List(1, 2, 3)  // Not found: type t

List(1, 2, 3) match { case ls: List[t] => ... } // works as expected

[bishabosha]

for reference, this behaviour was intentional from when given patterns were first added
https://github.com/lampepfl/dotty/blob/d09981141ea16a98c654b98ca582b9626bf0ff0b/tests/neg/given-pattern.scala#L7

[bishabosha]

In the discussion at the dotty meeting we decided to resolve this with an error for given patterns in val definitions

[som-snytt]

I tried to exploit the desugaring as shown, for example an extractor in the pattern takes the given, but it's not in scope.

If nothing else, closing off this avenue will save folks many hours trying to pursue it.