Failing tests for type comparisons.#6080
Conversation
|
Thanks for surveying the foundations before building another storey. The inconsistency in arity checks in Let's see how we arrive at During typechecking of this pattern: We ask: is the scrutinee type of A similar check is made in Again, it seems likely that the arities will line up by construction. As an experiment, add an assertion into |
|
As to question 2, However (IIRC) it can happen with the way that typechecking of existential types creates type variables. |
c52e96d to
0bb3c82
Compare
0bb3c82 to
ed2d110
Compare
|
Added the assertion to I brought this up because in #6069, you asked for tests to "explore whether the change preserves transitivity of subtyping and consistency with |
|
Type vars also cause inconsistency between type Struct = { def i: Int }
// these are true
(?A with Serializable) =:= (Struct with Serializable)
(Struct with Serializable) <:< (?A with Serializable)
// but this is false
(?A with Serializable) <:< (Struct with Serializable) |
|
You might want to take a look at my WIP on the solver ... it addresses some ill-kinding issues. |
|
closing for inactivity. we can reopen if activity resumes |
These tests show that for types
Foo[A],Bar[A, B]and type variablesF[_],G[_, _]:?Gwith[A]Bar[A, A], which is incorrect because of the different number of type parameters (2 vs 1).Foo <:< ?Fand?F <:< [A]Bar[Int, A]simultaneously, which by transitivity meansFoo <:< [A]Bar[Int, A], which is not true.I don't know if these are reproducible through compilation, but they hinder my progress on correctly implementing and testing #6069.
For starters, is there agreement that these are bugs that need to be addressed?