Intersection type with refined type member as upper bound does not compile

[pweisenburger]

The following code compiles using Scala:

trait Test {
  type A <: Any { type T }
  type B <: Any { type T }
  type C <: A with B { type T }
}

Dotty produces the following compiler error:

4 |  type C <: A with B { type T }
  |            ^
  |            class Any is extended twice

Notably, the following code compiles:

trait Test {
  type A <: Any
  type B <: Any
  type C <: A with B
}

[smarter]

More succinctly, the issue is that we cannot type:

Any with Any { type T }

(or any other refinement that looks like X with X { ... })
Because typedRefinedTypeTree will type the following synthetic trait (using desugar.refinedTypeToClass):

trait <refinement> extends Any with Any { type T }

and we do not allow the same class to appear twice in the extends clause. I don't think we can relax this restriction for the synthetic <refinement> traits, since that probably breaks assumptions somewhere else. Instead it might be possible to normalize the extends clause we generate to not contain the same class twice (but event that is not trivial if we want List[Any] with List[String] { type T } to compile).

[pweisenburger]

Okay, I see the problem. However, since you can easily construct concrete types for the abstract type members, I think you would assume that the code compiles.

and we do not allow the same class to appear twice in the extends clause

Is it important to disallow multiple appearances of the same type? This means the following does not compile:

trait L[+T]
trait T extends L[Any] with L[String]

But this does:

trait L[+T]
trait A extends L[Any]
trait B extends L[String]
trait T extends A with B

Naively, both variants look similar. For both, L appears twice in the set of base types. Would it make sense to define linearization in a way that L appears only once in the linearization of trait T extends L[Any] with L[String] to solve those kinds of issues? I guess that's what's happening for trait T extends A with B.

it might be possible to normalize the extends clause we generate to not contain the same class twice

Isn't the logic that is already implemented to compute the linearization basically what is required here; or do I see that wrong?

[smarter]

Right, so maybe we can indeed lift this restriction just for typing refinements and nothing bad will happen. (It could also be lifted in general but there's no reason for a user to write trait T extends L[Any] with L[String], it's more likely to be a mistake).

[pweisenburger]

Thanks, sounds good :-)

It could also be lifted in general but there's no reason for a user to write trait T extends L[Any] with L[String], it's more likely to be a mistake

That's true, I agree.

[Blaisorblade]

Instead it might be possible to normalize the extends clause we generate to not contain the same class twice (but event that is not trivial if we want List[Any] with List[String] { type T } to compile).

(It could also be lifted in general but there's no reason for a user to write trait T extends L[Any] with L[String], it's more likely to be a mistake).

Or it could arise through type aliases that arise elsewhere and are hard to modify. I'm fine with forbidding direct appearances, though that could also be just a warning.

(I thought #4557 was related, but on a closer look it's probably not).