Radek Szymczyszyn

> Interestingly, we already conditionally use `eep:open/5` or `eep:open/1`. When we're at it we could also change the dynamic check to a preprocessor `ifdef`. It would fix the need for...

@aleklisi Did you have a chance to try [the workaround](https://github.com/josefs/Gradualizer/issues/426#issuecomment-1152968300) proposed by @berbiche?

I was thinking something similar. In general, the type var related bugs will only be fixable once we have a constraint solver, but we could store the constraints already instead...

For some context, `atom()` in general is not `refinable` - I'm guessing this is the sole reason: ``` 9> Type = fun (T) -> typelib:remove_pos(typelib:parse_type(T)) end. #Fun 10> typechecker:refinable(Type("atom()"), [])....

For more context, singleton atoms or a union of explicit atoms are accepted in complex types: ```erlang -type complex_t() :: {string, string()} | {list, list(allergen())} | {atom, example_atom | another_atom}...

> I don't agree about switching. I get that. My question was to be read more as "how should we match the function clause with the spec clause" and not...

> Maybe it's not going to be a problem in practice. Hmm, I imagine one might want to write a function like the following: ```erlang -spec classify(integer()) -> integer; (_)...

@VincentVanBork Sure, feel free to do so. It's not fixed yet. It's a missing clause in the aforementioned function.

I was thinking of a placeholder, e.g. ``. Technically, it's not a valid pid itself, but I imagine it would be good enough. What do you think?

Hmm, yeah, indeed. This is trickier than it seemed to be :D However, we know that the value returned from `pick_value` is only actually used for printing - we could...