Skip to content

Can't call ._1 on values inferred by a GADT match to be a tuple #16590

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
felher opened this issue Dec 26, 2022 · 1 comment · Fixed by #16766
Closed

Can't call ._1 on values inferred by a GADT match to be a tuple #16590

felher opened this issue Dec 26, 2022 · 1 comment · Fixed by #16766
Assignees
Milestone

Comments

@felher
Copy link
Contributor

felher commented Dec 26, 2022

Compiler version

3.2.1

Minimized code

enum Tag[A]:
  case MyTuple extends Tag[(String, String)]

def printIt[A](t: Tag[A], a: A): Unit =
  t match
    case Tag.MyTuple => println(a._1)

Output

value _1 is not a member of A
where:    A is a type in method printIt with bounds >: (String, String) and <: (String, String)

Expectation

Should compile fine, since the compiler knows that it is <: (String, String) and (String, String) should have _1. FWIW, annotating the type works. I.e.

    case Tag.MyTuple => println((a: (String, String))._1)

compiles fine.

Scastie Link:

https://scastie.scala-lang.org/4sovEbRjTJOlv0g5WNEUTw

@felher felher added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Dec 26, 2022
@felher felher changed the title Can't call _.1 on values inferred by a GADT to be a tuple Can't call ._1 on values inferred by a GADT to be a tuple Dec 26, 2022
@felher felher changed the title Can't call ._1 on values inferred by a GADT to be a tuple Can't call ._1 on values inferred by a GADT match to be a tuple Dec 26, 2022
@dwijnand dwijnand added area:gadt and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Dec 26, 2022
@SethTisue
Copy link
Member

SethTisue commented Jan 25, 2023

Looking at this with Dale.

Both the case class representation and the generic representation of 2-tuple print as (String, String) – if you reach in and make them print differently, you find that in this case the lower bound is the Tuple2 case class but the upper bound is the generic version.

But that mismatch doesn't itself mean that something has already gone wrong. It's the upper bound that matters for member selection and calling ._1 on the generic version should of course work, and in normal circumstances it does. But not when GADT selection healing is needed, apparently!

A related recent fix to typedSelect was #16638, making extension method lookup take GADT constraints into account. typedSelect also has special code for selections on generic tuples, so we guess that code needs a comparable change.

@dwijnand dwijnand linked a pull request Jan 25, 2023 that will close this issue
@Kordyjan Kordyjan added this to the 3.3.1 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants