Type not found in derived class when extending trait with inner class type projection and F-bound

[readren]

Compiler version

Checked with 3.6.2 and 3.6.3

Minimized example

I posted this in stackoverflow and DmytroMitin suggested me to post it here also.

The following scala3 code compiles as expected:

	trait Product

	trait Provider[+P <: Product] {
		def provide: P
	}

	class Outer extends Provider[Outer#Inner] {
		override def provide: Inner = new Inner
		class Inner extends Product
	}

	class DerivedOuter extends Outer {
		override def provide: DerivedInner = new DerivedInner
		class DerivedInner extends this.Inner
	}

But if DerivedOuter also extended any type T[X] where X is a projection of a inner class of DerivedOuter, the compiler complains with a message that does not clarify the problem for me.

	class DerivedOuter extends Outer, Provider[DerivedOuter#DerivedInner] {
		override def provide: DerivedInner = new DerivedInner
		class DerivedInner extends this.Inner // <--- type `Inner` is not a member of `DerivedOuter`
	}

The problem arises when DerivedOuter also extends Provider[DerivedOuter#DerivedInner] (or any other trait with the same type argument).

Output Error/Warning message

The compiler complains at the line commented above saying:
type Inner is not a member of DerivedOuter

Why this Error/Warning was not helpful

The message was unhelpful because it gives no clue about which constraint, if any, causes the error.

Suggested improvement

I'm not even sure if the compiler should complain, let alone what the correct message should be if there should be any complaint at all.

[som-snytt]

It seems to get its wires crossed when checking parent types.

trait T[Q]

class Outer:
  class Inner

class DerivedOuter extends Outer, T[DerivedOuter#DerivedInner]:
  class DerivedInner extends Inner

omitting this increases the humor:

Not found: type Inner - did you mean Integer?

[readren]

I’m surprised this bug was only discovered now. Does no one use inner classes, path-dependent types, and type projections? I consider them very useful. Or perhaps they were only used for trivial things due to the limitation imposed by this bug.

[SethTisue]

Does no one use inner classes, path-dependent types, and type projections?

All three of those features are in wide use. I suspect you are overestimating how common it is for someone to hit on this very particular way of combining them.

Regardless, thanks for the report, it's valuable.

[SethTisue]

I've observed that on Scala 2 (2.13.16), even Outer doesn't compile, let alone DerivedOuter

error: illegal cyclic reference involving class Outer

Scala 2 and 3 tend to differ in various ways on how they handle cyclic references: accept vs. reject, plus the third possibility of accept but handle incorrectly.

[readren]

It wasn’t my intention to criticize the work of the language developers. They created a masterpiece. Odersky is one of my heroes.
I was referring to the users because surely many of them encountered this issue and didn’t report it. And I include myself in that, because I wouldn’t have reported it if it weren’t for Dmytro Mitin.

[SethTisue]

It wasn’t my intention to criticize the work of the language developers

cool, no worries

surely many of them encountered this issue and didn’t report it

That's conceivable, but to say "surely" seems like a big reach to me. I'm basing on this on my long experience in doing triage in the Scala 2 and 3 bug trackers. Certain bugs get hit and reported (and asked about in chat rooms and forums and Stack Overflow) over and over again. Other bugs get reported once and then never again for a decade or more.

I don't know for sure which kind of bug this one is, but you should understand that just because you hit a bug doesn't mean that "surely" "many" other users are hitting it as well. Occasionally that's the case; usually it isn't.

[som-snytt]

There is some type projection philosophy or lore at #18655

The restriction is at https://dotty.epfl.ch/docs/reference/dropped-features/type-projection.html

Scala 3 doesn't cope as well with F-bounds, which is taken as a limitation, so it's not surprising that this doesn't work.

It may be a case of "idioms which are well supported."

[SethTisue]

Ah, nice find! (18655) Nice meaty discussion on that one.

I agree that the cyclic/F-bounded nature of the code is critical here. It's not just that inner classes, path-dependent types, and type projections are all in play. The trouble comes when a fourth and notoriously fragile feature, namely F-boundedness, joins.

[readren]

I don't get the f-bound polymorphism part. Which of the involved traits/clases is f-bound polymorphic? The only explicitly polymorphic trait is Provider (or T in @som-snytt example) and its type parameter is not constrained by itself. Does any of traits/classes of the examples have an implicit type parameter constrained by itself? Or does "f-bound" mean another thing?