"illegal cyclic reference" again

[dubinsky]

reproduction steps

object IllegalCyclicReference {
  trait Number[S <: Numbers[S], N <: Number[S, N]] { this: N => }
  trait PointNumber[S <: Numbers[S]] extends Number[S, S#Point] {
    this: S#Point => } // Error No 1
  trait Numbers[S <: Numbers[S]] { this: S =>
    type Point <: PointNumber[S]
  }
  trait Times[S <: Times[S]] extends Numbers[S] { this: S =>
    override type Point <: PointNumber[S] with Number[S, S#Point]  // Error No 2
  }
  trait Angles extends Numbers[Angles] {
    override type Point = PointNumber[Angles]
  }
}

problem

With Scala 2.13.0, 2.13.1 and 2.13.2:

[Error No 1] ... illegal cyclic reference involving trait PointNumber
[Error No 2] ... illegal cyclic reference involving type Point

expectation

BUILD SUCCESSFUL

like with Scala 2.12.10 :)

I do not understand if this is related to #11640 (or #11734) or is actually illegal in Scala 2.13 (and Dotty). I wasn't able to find a work-around :(

[dubinsky]

I was thrilled when I realized that Scala can encode family polymorphism that Java can not;
even more so when I found out that this can be done for production-size code, with family members placed in separate files, not co-located in one trait or object, and not assembled with the cake pattern (ugh). Above error-producing snippet was extracted from a somewhat larger code base that crucially depends on such encoding.

It's been a year since Scala 2.13 broke this code. Multiple tickets that sound related to this issue had been opened; some were closed. This ticket was opened almost two months ago and did not see any activity since.

I would really like to know: was this kind of code never legal, and family polymorphism encoding that I use only compiled (and run) prior to Scala 2.13 by mistake, or is there a bug in Scala 2.13.0, 2.13.1 and 2.13.2 compiler and Dotty compiler up to 0.26? If it is the former, I guess I need to start looking for alternatives; if it is the later, I'd like to have some idea about the timeline of the fix :)

Since Scala type system is on solid foundation for the last 6 years, it shouldn't take somebody who is familiar with that foundation long to make the determination here. Do you think this can be arranged?

Thanks!

[dubinsky]

@SethTisue ?

[dubinsky]

@odersky sorry to bother you directly, but I do not see any other way to find out if the 10-lines code snippet above is legal Scala...

[odersky]

With illegal cyclic references the truth is basically what the compiler says. The compiler has an enormous amount of code and intelligence devoted to not getting it into infinite loops and stack-overflows, at least for the most part. The only argument would be to point out that a cyclic reference is not necessary since there is a reasonable way to avoid it.

But the code given won't be legal Scala 3 anyway because of the S#Point construction (see the "type projections" part of the dotty reference).

[dubinsky]

Thank you for a speedy reply!

With illegal cyclic references the truth is basically what the compiler says.

So, what is legal with Scala 2.12 compiler is illegal with Scala 2.13 compiler, and both are correct?
No possibility of a compiler bug, numerous issues alleging such bugs in the cycle-detection notwithstanding?

cyclic reference is not necessary since there is a reasonable way to avoid it

Any pointers to the way to avoid such cyclic references?

the code given won't be legal Scala 3 anyway because of the S#Point construction

That's what I expected, but Dotty 0.26 compiler did not complain about general type projection...

Do you know of any examples, discussions or papers on family polymorphism encoding in Scala such that it:

• allows family members to reside in separate files, with no enclosing traits (or cakes);
• works for Scala 3 (no abstract type projections);
• works for Scala 2.13 (no Scala 3-specific features required)?

Thanks!

[smarter]

That's what I expected, but Dotty 0.26 compiler did not complain about general type projection...

Yeah it's not disabled yet, it requires using -source 3.1 currently.