Ulf Norell
Ulf Norell
This feels like a perfect candidate for a flag. You could enable it when type checking existing code exploiting that records are tuples, but leave it disabled when developing new...
In addressing #72 (PR: #83), I changed the type of `andalso` and `orelse` to precisely what @Zalastax suggested: `(a: boolean, b: T) => boolean | T`.
It would be ```erlang -spec andalso(boolean(), false | T) -> false | T. -spec orelse(boolean(), true | T) -> true | T. ``` but yes, this is a straightforward change.
Well if `T = true` (i.e. checking against `boolean()`) it would be strange to require the second argument to `andalso` to always be `true`... But also we're pushing types in...
Sure. The first point still stands though: we shouldn't give a type error on `B andalso false :: boolean()`.
The second operand is an expression that should be checked against some type, not a type that should be a subtype of some other type. We can check `A andalso...
This is indeed the most precise type, but I don't think we have the ability to check it at the moment.
I am little confused about what we're talking about here to be honest. The way we would actually check `andalso` is: ``` subtype(false, R) check(A, boolean()) check(B, R) -------- check(A...
In the first case how would you pick `T`? It really needs to be `R` since `B` might have precisely the type `R`. The second case is just wrong. If...
> it's completely fine that `andalso(true, false) :: false` The typing rule I suggested delivers this. We would check (since `A = true`, `B = false`, and `R = false`)...