4 ms·

I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption th

I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption that true equals 1 and false equals 0. I think that Rust got this right. It doesn't allow you to add integer to boolean or multiply boolean by float etc, because it is unclear what does it even mean mathematically. Also, most languages implicitly assume that any value of any type is either "truthy" or "falsy" thus you can do something like `while(1) { do_stuff() }`. Rust doesn't allow this BS, `if` and `while` expect a boolean so you have to provide a boolean.

flakes 2y ago
A lot of languages have no boolean primitive to begin with. Often in older languages, the values for `true` and `false` are aliases for `0` and `1` respectively. Perl and earlier versions of C, Python, and JavaScript are notable. Perl is probably the most awkward due to context-sensitive casting. e.g. the string `"0"` in a boolean context evaluates as an integer, and the boolean interpretation for `0` is false.
- erik_seaberg 2y ago
  Sometimes Perl uses "0E0" as a value that is equal to zero yet not false. Javascript has even more cases where equality isn't transitive.
- int_19h 2y ago
  JavaScript had Booleans as a primitive type as far back as I can remember. The problem, rather, is that it's altogether too eager to convert everything into everything else.
int_19h 2y ago
That resolves the problem for other types, but you still have the case of (a == b == c) being parsed and evaluated as ((a == b) == c) if all three are booleans, which is still not an intuitive interpretation. I think the PL either has to ban such construct outright and require parentheses, or treat it as an n-ary operator like Python does (albeit perhaps with a few more constraints on what you can chain, for the sake of readability).
- throwaway313373 2y ago
  I've just checked [0], Rust bans such construct for booleans as well. [0] https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=251e09e9dd66a9e653eace3a075a6a4a https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - quietbritishjim 2y ago
    That is impressive.
  - int_19h 2y ago
    Great error message, too.

flakes 2y ago

A lot of languages have no boolean primitive to begin with. Often in older languages, the values for `true` and `false` are aliases for `0` and `1` respectively. Perl and earlier versions of C, Python, and JavaScript are notable. Perl is probably the most awkward due to context-sensitive casting. e.g. the string `"0"` in a boolean context evaluates as an integer, and the boolean interpretation for `0` is false.

erik_seaberg 2y ago
Sometimes Perl uses "0E0" as a value that is equal to zero yet not false. Javascript has even more cases where equality isn't transitive.
int_19h 2y ago
JavaScript had Booleans as a primitive type as far back as I can remember. The problem, rather, is that it's altogether too eager to convert everything into everything else.

int_19h 2y ago

That resolves the problem for other types, but you still have the case of (a == b == c) being parsed and evaluated as ((a == b) == c) if all three are booleans, which is still not an intuitive interpretation. I think the PL either has to ban such construct outright and require parentheses, or treat it as an n-ary operator like Python does (albeit perhaps with a few more constraints on what you can chain, for the sake of readability).

throwaway313373 2y ago
I've just checked [0], Rust bans such construct for booleans as well. [0] https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=251e09e9dd66a9e653eace3a075a6a4a https://play.rust-lang.org/?version=stable&mode=debug&editio...
- quietbritishjim 2y ago
  That is impressive.
- int_19h 2y ago
  Great error message, too.