Pierre Krafft

I'd argue that the function actually has the spec `f(#{any() => any()) -> ok`. The documentation is quite specific in disallowing more associations. Unfortunately it doesn't talk about subtyping but...

Yes, I think the commit looks good! I don't know why the more complicated way was chosen. ________________________________ From: Viktor Söderqvist Sent: Thursday, December 10, 2020 4:10:10 PM To: josefs/Gradualizer...

We've had similar discussions elsewhere but it's good to have it again! I think we should not fail on this. It is a bit inefficient but it's not wrong. Could...

It's a good idea but the current type system doesn't recognize a module as something other than an atom. It would be interesting but unless we think this is an...

That is not expected: > A map association has a key in AssociationList if it belongs to this type. AssociationList can contain both mandatory (:=) and optional (=>) association types....

Isn't `#{two := two} two, one => one}`? I think the current inference is correct. `#{two => two}` has the type `#{two := two}` since the key value pair is...

> Non-boolean values as second argument are already allowed as the default behavior in Gradualizer! Just don't write any type specs! I find this statement controversial. To me, the static...

@josefs I was not really arguing for any side. Instead I was stating that I don't think we should lean on the fact that it's possible to opt out from...

Don't we get `B andalso false :: boolean()` automatically via widening? The type of that expression *is* `false` but that's a subtype of `boolean()` so no cow on the ice....

Might be so. What about widening then? Don't we get away with `B andalso false :: false ∧ false