F-bounded type cannot be used in type member - Cyclic reference

[Sciss]

The new "fix" for disallowing some F-bounded types (cf. #10256) disallows some perfectly valid code.

Minimized code

package woes

trait Txn[T <: Txn[T]]

trait Impl[Repr[~ <: Txn[~]]] {
  final type Ext = Extension[Repr]  // Huh!
}

trait Extension[Repr[~ <: Txn[~]]]

Output

/data/temp/DottyFBoundedWoes/src/main/scala/woes/Woes.scala:9:27
Cyclic reference involving type Repr
trait Extension[Repr[~ <: Txn[~]]]

Expectation

Adding the fixed type Ext to Impl shouldn't cause the compiler to reject the definition of Extension.

[smarter]

Looks like it works when the definitions are in a different order:

package woes

trait Txn[T <: Txn[T]]

trait Extension[Repr[~ <: Txn[~]]]

trait Impl[Repr[~ <: Txn[~]]] {
  final type Ext = Extension[Repr]  // OK
}

[Sciss]

Ah, yes, this might be, when I tried to minimise, the errors strangely jumped from place to place. In my actual code base, they are in four different files. I'll try to move some to the same file

[odersky]

I am quite pessimistic we can solve this. As I wrote in a different issue, the fact that Scala 3 has intersection types and that it uses intersection rather than linearization for joining members means that it will run into more cyclic references for F-bounded types. There's not much we can do, and I am also not sure who would attempt to fix this (it won't be me).

In the meantime, let's label all bugs with F-bounds with a label. That means that anyone who takes it on themselves to address them has the whole picture of all the issues.

[Sciss]

Ok, this is not "minimised", but reproducible.

git clone --single-branch -b dotty-10638 https://github.com/Sciss/Lucre.git
cd Lucre/
sbt ++3.0.0-M2 exprJVM/compile

I tried to remove some intermediate classes. Still, at some point classes like BooleanTuple1s refer to ExprTypeExtension1, and the errors occur. I don't see a way how I can "order" the compilation order here.

Also I want to point out, there is nothing cyclic here. BooleanTuple1s is an "end type", nothing extends that in any way.

[odersky]

The cycles are inherent in the F-bounds. Every F-bound is a cycle. It depends on what else the compiler is doing to find out whether that cycle is a problem or not. Many of them lead to problems, and are consequently rejected. Scala 3 by its design makes more F-bounds problematic than Scala 2. It's a thoroughly unsatisfactory solution, which makes me wish we did not have F-bounds. So my advice is probably not very welcome but I don't know what else to say: try to get rid of F-bounds as much as possible in Lucre.

[odersky]

Here's a systematic way to remove F-bounds from your code. It's inspired by the algebraic subtyping encoding from Stephen Dolan's PhD thesis:

If you have an F-bounded type T <: F[T] simply replace it with T. Then everywhere T is used, replace it with T & F[T].

I tested that strategy with the example from @tpolecat's blog on F-bounds.
Here's how it comes out:

trait Pet[A]:
  this: A =>
  def name: String
  def renamed(newName: String): A & Pet[A]

case class Fish(name: String, age: Int) extends Pet[Fish]: // note the type argument
  def renamed(newName: String) = copy(name = newName)

def esquire[A](a: A & Pet[A]): A & Pet[A] = a.renamed(a.name + ", Esq.")

val a = Fish("Jimmy", 2)
val b = a.renamed("Bob")
val c = esquire(b)

Maybe this shows up a way how to get rid of F-bounds altogether over time? Since they are so fragile, this would be an improvement from a language design standpoint, IMO.

[odersky]

I could fix this in #10972.