Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Compiler cannot identify the equivalence of two abstract types that resolves to identical symbol #12046

Open
tribbloid opened this issue Jun 20, 2020 · 5 comments
Open

Compiler cannot identify the equivalence of two abstract types that resolves to identical symbol #12046

tribbloid opened this issue Jun 20, 2020 · 5 comments
Labels
dealias compiler isn't dealiasing when it should, or vice versa dependent types fixed in Scala 3 This issue does not exist in the Scala 3 compiler (https://github.com/lampepfl/dotty/)
Milestone
Backlog

Comments

@tribbloid
Copy link

(Original post: https://stackoverflow.com/questions/62478001/in-scala-how-to-instruct-the-compiler-to-realise-the-equivalence-of-two-abstrac)

reproduction steps

using Scala (2.12.11, 2.13.2),

    trait Super1[S] {

      final type Out = this.type
      final val out: Out = this
    }

    trait Super2[S] extends Super1[S] {

      final type SS = S
    }

    case class A[S](k: S) extends Super2[S] {}

    val a = A("abc")

    implicitly[a.type =:= a.out.type]
    // success

    implicitly[a.Out =:= a.out.Out]
    // success

    implicitly[a.SS =:= a.out.SS]
    implicitly[a.SS <:< a.out.SS]
    implicitly[a.out.SS <:< a.SS]
    // oops

problem

if I move:

      final type Out = this.type
      final val out: Out = this

to be under Super2 it will compile successfully.

the path-dependent type resolver behave inconsistently just for this case. My questions are:

  • How to visualise the type representation of abstract types? (e.g. printing a tree of all supertypes, constraints & type parameters etc.)

  • What is the root cause that cause this problem, can it be identified by the used visualisation?
@SethTisue SethTisue added the fixed in Scala 3 This issue does not exist in the Scala 3 compiler (https://github.com/lampepfl/dotty/) label Nov 11, 2020
@dwijnand dwijnand added this to the Backlog milestone Nov 11, 2020
@dwijnand
Copy link
Member

I'm not 100% certain, but the fact that I can be convinced it should compile and the fact that it does in Dotty strengthens that for me. The parent trait (Super1) part of it is also interesting - are type parameters different than this.type, in terms of soundness, here? 🤔

@SethTisue
Copy link
Member

In general, dealiasing is a fraught topic in scalac and there are lot of issues in the general area of "this should have been dealiases" what wasn't. I wonder if this might actually be a duplicate?

@tribbloid
Copy link
Author

@SethTisue are there other tickets caused by dealiasing of non-this type?

@SethTisue SethTisue added the dealias compiler isn't dealiasing when it should, or vice versa label Nov 11, 2020
@SethTisue
Copy link
Member

I don't know. It's difficult, looking at multiple reports like this, to determine which ones are the “same” or not. It's difficult to even find tickets which are about dealiasing. (I only created the "dealias" label just now.)

@som-snytt
Copy link

"Issue tracker cannot identify the equivalence of two abstract tickets that resolve to the identical issue."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
dealias compiler isn't dealiasing when it should, or vice versa dependent types fixed in Scala 3 This issue does not exist in the Scala 3 compiler (https://github.com/lampepfl/dotty/)
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
4 participants
@SethTisue @dwijnand @som-snytt @tribbloid