Improve type system and type inference rules
k-sareen opened this issue · comments
As discussed here: #120 (comment), the type system and inference rules should be updated to allow less verbose pattern matching for developer UX.
Can you write a seman
testcase that should pass and add to test/fail
?
I've been reading the type checking code in vst/Verifier.v3
and I don't understand why the ve.expr
has to be null
, i.e. why the match case has to be the unqualified type (see these lines).
For the error generated by test/fail/adt_type_infer03.v3
(in PR), I think the TypeSystem.isPromotable()
should return true
because, well A<u4>.C
and A<u8>.C
are the exact same type. Unless is there some internal representation issue? Even then it should just be equal, no?
EDIT: Or well, more precisely the TypeSystem.isSubtype()
for variants needs updating.
This is a subtle thing that needs to be explained better. Integer types like u4
and u8
are not related by subtyping but by promotion. That is because they could be represented differently. E.g. on a 32-bit machine a u32
will be represented by one word and u64
two words. Subtyping is only for values whose representation doesn't change when assigning a value from a subtype to a supertype location (i.e. the assignment is always pass-through, nop).