This is a fix for #5980.
I have not found a proof anywhere that
Also, it seems that the bug originates not really because of the distribution itself but because of inconsistent treatment of how subtyping relationship is inferred for traits and type params. Even if the
Consider that we need to compute
The difference between how traits and type params are treated originates at the match inside compareAppliedType2 of
In case of ClassInfo, the branch will ultimately lead us to this line which computes the
To summarise, when inferring
This PR adds such a check to the corresponding inference logic.
The text was updated successfully, but these errors were encountered:
More thoughts on why
If used on types which cannot be simplified,
So basically in all cases, in case of type parameters, the semantics of
However, I'm not completely sure whether it makes for the consistent subtyping behaviour between type params and traits since there's a lot going on there. Would appreciate some feedback on the above logic regarding whether
…ructors When performing subtyping comparisons of the `F[A] & F[B] <:< C` kind, if `F` is a type parameter (e.g. as in `trait Foo[F[+_]]`), the compiler decides the relationship to be true if either `F[A] <: C` or `F[B] <: C`. However, in case of covariant `F[+_]`, it is possible to distribute the type arguments when performing the `&` operation: `F[A] & F[B] ~> F[A & B]`. Hence there is one more case to be considered when checking `<:<` relationship. This commit adds such a check to the `<:<` logic. Now, `F[A] & F[B] <:< C` is true (for covariant `F`) if either of the following is true: - F[A] <: C - F[B] <: C - F[A & B] <: C