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?

[SethTisue]

it's possible we're throwing "F-bound" around in a way that doesn't quite fit the formal definition? I'm not sure

the canonical example of F-bounded polymorphism is

trait Container[A]
trait Contained extends Container[Contained]

where Contained has a supertype that references Contained itself; a similar cycle is present in class DerivedOuter extends Outer, Provider[DerivedOuter#DerivedInner]. DerivedOuter is defined in terms of itself.

[readren]

... a similar cycle is present in class DerivedOuter extends Outer, Provider[DerivedOuter#DerivedInner]. DerivedOuter is defined in terms of itself.

Is it? Does the DerivedOuter#DerivedInner type depend on the DerivedOuter type? Isn't a projection type like DerivedOuter#DerivedInner a type that may be defined outside and independently of the parent DerivedOuter? Like a facade trait that generalizes the type aInstanceOfDerivedOuter.DerivedInner removing the constraints related to the DerivedOuter type and instance?

The workaround I suggested in stackoverflow does exactly that: replaces the projections type with a facade interface equivalent to it.

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

    trait DerivedInnerFacade extends InnerFacade
    class DerivedOuter extends Outer, Provider[DerivedInnerFacade] {
        override def provide: DerivedInner = new DerivedInner
        class DerivedInner extends this.Inner, DerivedInnerFacade
    }

Or am I missing something and the projection type must have constraints toward its parent that I don't see?

[SethTisue]

Is it? Does the DerivedOuter#DerivedInner type depend on the DerivedOuter type?

Yes

Isn't a projection type like DerivedOuter#DerivedInner a type that may be defined outside and independently of the parent DerivedOuter?

I'm at a loss at how to answer, as I don't follow your thinking here.

Your workaround code might be a different way of reaching your goal, whatever your goal is, but projection types don't desugar to this workaround. They might be "equivalent" to you as a user as some sense, but they aren't equivalent in the compiler.

[readren]

I don't want to waste your precious time. Respond only if you enjoy it.
The questions are based on the following code:

class Outer {
    class Inner
}
val outer = new Outer

Questions:

1. If the compiler treated the projection type Outer#Inner as a generalized type InnerGen—effectively removing the constraints tied to the specific instance outer and the type Outer—what would no longer be possible, or what would become unsound in the type system?

2. If there are reasons that prevent the projection type Outer#Inner from being equivalent to InnerGen, wouldn't it be beneficial for the language to introduce a way to represent InnerGen directly, for example Outer@Inner? This would avoid requiring users to define InnerGen manually:

trait InnerGen
class Outer {
    class Inner extends InnerGen
}
val outer = new Outer
val inner: outer.Inner = new outer.Inner
val innerProjection: InnerGen = inner

Note that the InnerGen trait has to duplicate the signature of all the members of Outer#Inner.