Open gilbertwong96 opened 7 months ago
To support this example, we need complex reasoning about patterns and types to eliminate the types matched by the left hand side of ?=
from the right hand side.
This is something we currently do not support but would like to, although it is very difficult in the general case (where the pattern is more complex than an atom).
I plan to investigate this during the coming year.
I plan to investigate this during the coming year.
@VLanvin isn't this needed for maybe support? In the meantime should we have eqwalizer not run in maybe blocks? Or all maybe blocks will need % eqwalizer:fixme
comments?
isn't this needed for maybe support? In the meantime should we have eqwalizer not run in maybe blocks? Or all maybe blocks will need
% eqwalizer:fixme
comments?
A lot can already be done with maybe blocks and eqWAlizer, such as binding variables via patterns, e.g., {ok, V} ?= foo(Arg)
. The type of V
here will be correctly refined according to the spec of foo/1
.
More complex behaviour that mixes predicates, patterns, and booleans such as what is being proposed here, is what is not supported currently.
I don't think it's worth disabling eqWAlizer in maybe blocks for such cases, as we can indeed use % eqwalizer:fixme
comments. If the use-case becomes too frequent, then we can re-consider.
I wrote codes with the
maybe feature
like this:I suppose the type spec is correct. However, the eqwalizer reports the error
incompatible_types
.The entire output is as below:
Could you please give me an explanation ?