grain
grain copied to clipboard
Same-module type alias unification issue
If I create a parameterized type alias and then create a weakly typed value of that type, unification does not occur:

It's easy to tell here via foo
still being reported as weak even though I used a function which should have given it a concrete type.
Interestingly enough, this does not occur for enums:

Even more interesting, this doesn't occur and the types are correct if the type/functions are declared in another module:

It also looks like typechecking becomes completely broken and the annotation is ignored entirely if you try to resolve types that way (Int32
!= String
):

@ospencer it makes sense, Foo is not injective. Foo<String> = Foo<Int32> that doesn't mean Int32 = String.
On the second case there is nothing to expand Foo too, maybe the second case could be considered a bug, but as Grain doesn't have enhanced value restriction this is the expected behavior.
The LSP error is also shadowed by having the enhanced value restriction, as in the first case the type would be Foo.
@EduardoRFS Yeah, that makes sense, and it works in the cases you'd actually want to use this. I'll close this issue, but we'll open another one to look into enhanced value restriction.
cc @phated 😄