Open tribbloid opened 4 years ago
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? 🤔
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?
@SethTisue are there other tickets caused by dealiasing of non-this type?
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.)
"Issue tracker cannot identify the equivalence of two abstract tickets that resolve to the identical issue."
(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),
problem
if I move:
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?