In general, due to #512 there are many more union types being passed around in code, which leads to more places where we have to manually assert which union member we're dealing with. I think using guards more extensively would:
allow for avoiding mundane refactorings such as some of those done in #512, which are currently necessary to satisfy the type checker, but lead to clunkier and less natural Erlang,
play well with the idea of gradual typing; guards carry extra information that could help our static analysis, but currently this information is most often discarded; #501 touches on how we could use guards to provide more feedback, too.
This PR defines just one known problem because so far I only managed to isolate one from #512 changes, but I remember there were more cases like this. Not all are equally easy to reproduce, i.e. sometimes it's not obvious why Gradualizer can't tell which union member it's dealing with. This is connected with how we represent gradualizer_type:abstract_type().
This defines a known problem for one of the type check errors we discussed in https://github.com/josefs/Gradualizer/pull/512#discussion_r1122806508.
In general, due to #512 there are many more union types being passed around in code, which leads to more places where we have to manually assert which union member we're dealing with. I think using guards more extensively would:
This PR defines just one known problem because so far I only managed to isolate one from #512 changes, but I remember there were more cases like this. Not all are equally easy to reproduce, i.e. sometimes it's not obvious why Gradualizer can't tell which union member it's dealing with. This is connected with how we represent
gradualizer_type:abstract_type()
.