Handling aliases correctly

[TheGeorge]

Currently the following code

-spec test() -> {atom1, atom2} | atom3.
test() ->
    case f() of
        {atom1, _} = X -> X;
        _ -> atom3
    end.

-spec f() -> {atom1, atom2} | atom4.
f() ->
    {atom1, atom2}.

gives me the error

The variable 'X' on line 7 has type {atom1, atom2} | atom4 but is expected to have type {atom1, atom2} | atom3

[josefs]

Gradualizer currently doesn't do type refinement based on patterns. So even though X is bound to a pattern which can only have the type {atom1, atom2}, Gradualizer doesn't detect this. X is given the type of the whole pattern.

I'd like Gradualizer to do more type refinement in the future, but I'm afraid it's not at the top of my todo list. If you disagree and think that this is a superimportant feature, please let me know. I might be persuaded to bump it up the list.

[zuiderkwast]

Shouldn't solving the constraints be enough in this case? It's not implemented, but from the pattern {atom1, _} = X, there should be a constraint X :: {atom1, _} which can be used to eliminate atom4.

[josefs]

@zuiderkwast, your suggestion implies that we can infer the type of the pattern. I suppose we could attempt to do that, but it's not something we currently do.

[josefs]

I just want to mention that I've come across this problem myself now. I didn't write the code but I've type checked a few modules which use this idiom.