Closed k-sareen closed 1 year ago
I'll tinker with these tests a bit.
As discussed in #131. Some explanations for my reasoning these are type inference bugs:
- I would argue that
adt_type_infer01.v3
is a type inference bug instead of a syntax bug as it should easily be able to infer thata
is of typeA<u4>
so it should not be complaining aboutMatchError: match on type A<u4> requires unqualified case
. This would also allow deconstructing the case expression like with other ADTs.
The rule is that matching on an ADT either deconstructs, in which case you don't qualify the cases, or it is a type-case, in which you need to write full types. It doesn't currently do unification on the target type of a type-case, maybe it should.
adt_type_infer02.v3
complains aboutTypeError: type "A" expects 1 type arguments and found 0
andMatchError: key of type A<u4> can never match type A.B<?>
among other things. Again, it should be able to infer thata
is of typeA<u4>
inside thematch
statement.
This is the unification thing above, it can't figure out the type argument. This test had other bugs; the C case cannot be arbitrarily re-used across different instantiations of A
adt_type_infer03.v3
is the closest to what we have to do currently to match an ADT with a type parameter, but it can't infer thatA<T>.C
andA<U>.C
are the same types.
They aren't the same types. A<T>.C
and A<U>.C
might be represented completely differently, even if the C
case doesn't mention the type parameter.
- The
adt_type_infer04.v3
test is just a combination ofadt_type_infer01.v3
andadt_type_infer02.v3
.
adt_type_infer0{2,3,4}
use the return value fromg()
in the way we have to do currently. Just added it for sanity that we are using the return value fromg()
and as a test that this kind of matching should be allowed as well (I also didn't want to generate more errors than required).
The rule is that matching on an ADT either deconstructs, in which case you don't qualify the cases, or it is a type-case, in which you need to write full types. It doesn't currently do unification on the target type of a type-case, maybe it should.
I mean it would make it less verbose, so definitely better for developer UX.
This is the unification thing above, it can't figure out the type argument. This test had other bugs; the C case cannot be arbitrarily re-used across different instantiations of A.
Ah right. Interesting. Variants don't get passed by reference, I forgot.
They aren't the same types.
A<T>.C
andA<U>.C
might be represented completely differently, even if theC
case doesn't mention the type parameter.
That's fair. I checked with Rust and yeah I must have been misremembering because an equivalent program does not compile in Rust as well.
As discussed in #131. Some explanations for my reasoning these are type inference bugs:
adt_type_infer01.v3
is a type inference bug instead of a syntax bug as it should easily be able to infer thata
is of typeA<u4>
so it should not be complaining aboutMatchError: match on type A<u4> requires unqualified case
. This would also allow deconstructing the case expression like with other ADTs.adt_type_infer02.v3
complains aboutTypeError: type "A" expects 1 type arguments and found 0
andMatchError: key of type A<u4> can never match type A.B<?>
among other things. Again, it should be able to infer thata
is of typeA<u4>
inside thematch
statement.adt_type_infer03.v3
is the closest to what we have to do currently to match an ADT with a type parameter, but it can't infer thatA<T>.C
andA<U>.C
are the same types.adt_type_infer04.v3
test is just a combination ofadt_type_infer01.v3
andadt_type_infer02.v3
.adt_type_infer0{2,3,4}
use the return value fromg()
in the way we have to do currently. Just added it for sanity that we are using the return value fromg()
and as a test that this kind of matching should be allowed as well (I also didn't want to generate more errors than required).