Francois Brodeur
Francois Brodeur
It seems like some of them make sense. Considering usage is compared to expected. ```erlang subtype ( ? t ( # { a => b } ) , ? t...
From that description alone, it would mean `#{b := b}` is indeed not a subtype of `#{a => a, b => b}`, which is the initial example I gave. Unless...
The last change has only 1 failure then. One of them is a known problem being solved. Looking into it.
Alrighty then, name of the branch is bad but everything makes sense. Fixed a known problem, removed a failing test that was supposed to pass and added a few tests....
Found a problem. `no_match` catches too many things. If the same key is used wrong, should be an error. Fixing... ```erlang -spec optional_fail() -> #{a => a, b => b}....
@zuiderkwast so then this is wrong? The fact it says `a` *MIGHT* be in, does it change anything? It might not be there and therefore, valid. ```erlang subtype ( ?...
But should it work? I know this is a work around, I've used similar in the past like this #290 ```erlang -spec nth3([integer()]) -> integer(). nth3(Xs) -> case Xs of...
Ah I think you are right. It might tackle both of my open PRs then. Will try to compare output and close if needed.
It does pass, it's just something I saw while debugging some other bugs 🙃
Yea, I remember playing in the constraint part and it has integer ranges and such. So truly that's the best way, add whatever I find missing.