4 ms·

Bitwise OR and XOR on bools. Bitwise XOR is just !=, so it's useless. Bitwise OR isn't identical to any other operators, but writing code which specifically rel

Bitwise OR and XOR on bools. Bitwise XOR is just !=, so it's useless. Bitwise OR isn't identical to any other operators, but writing code which specifically relies on side-effects of a function on the RHS of an OR does not strike me as the sort of thing that the Go designers would approve of.

deleted 9y ago
[deleted]
CamperBob2 9y ago
Bitwise OR is equivalent to addition, but IMHO it makes more sense to omit support for addition on bools than to omit support for the classical boolean operators supported by C++. If for no other reason than to make existing C++ code easier to port.
- wbl 9y ago
  Addition on bools is XOR.
  - CamperBob2 9y ago
    Not by C++'s convention. It may be compiler-dependent, but all of the compilers I have within easy reach treat addition of bools as an 'or' operation. bool a = true; bool b = true; bool c = a + b; This leaves c set to true. Basically it gets promoted to int, turned into a value of 2, and demoted back to bool. Either way it's highly nonstandard not to implement a bitwise-or operation on a boolean type. It's a violation of the "principle of least surprise" as well as a portability hazard. No upside that I can imagine.
    - asveikau 9y ago
      I have been writing C for a while and never saw anyone add bools with +. Why do this when there is completely unambiguous || ? I get suspicious of being fast and loose with conversions between int and bool. This is implicitly required when working with operators like &&, ||, ==, etc., and working with pre-C99 bools and library typedefs. But assigning anything other than 1 or 0 is asking for problems. There is a whole class of bugs that shows up in security bugs involving assigning someone's machine-word-sized Boolean expression into someone else's byte sized bool, losing bits, and flipping from true to false. I sometimes feel there is a ^^ operator that should be there and is missing, in the same way that we have && and || corresponding to & and |. I have occasionally faked it with a macro: #define XOR(A,B) (((A) ? 1 : 0) ^ ((B) ? 1 : 0)) The ? here eliminates the problems from using larger != 1 quantities as true, as above.

deleted 9y ago

[deleted]

CamperBob2 9y ago

Bitwise OR is equivalent to addition, but IMHO it makes more sense to omit support for addition on bools than to omit support for the classical boolean operators supported by C++. If for no other reason than to make existing C++ code easier to port.

wbl 9y ago
Addition on bools is XOR.
- CamperBob2 9y ago
  Not by C++'s convention. It may be compiler-dependent, but all of the compilers I have within easy reach treat addition of bools as an 'or' operation. bool a = true; bool b = true; bool c = a + b; This leaves c set to true. Basically it gets promoted to int, turned into a value of 2, and demoted back to bool. Either way it's highly nonstandard not to implement a bitwise-or operation on a boolean type. It's a violation of the "principle of least surprise" as well as a portability hazard. No upside that I can imagine.
  - asveikau 9y ago
    I have been writing C for a while and never saw anyone add bools with +. Why do this when there is completely unambiguous || ? I get suspicious of being fast and loose with conversions between int and bool. This is implicitly required when working with operators like &&, ||, ==, etc., and working with pre-C99 bools and library typedefs. But assigning anything other than 1 or 0 is asking for problems. There is a whole class of bugs that shows up in security bugs involving assigning someone's machine-word-sized Boolean expression into someone else's byte sized bool, losing bits, and flipping from true to false. I sometimes feel there is a ^^ operator that should be there and is missing, in the same way that we have && and || corresponding to & and |. I have occasionally faked it with a macro: #define XOR(A,B) (((A) ? 1 : 0) ^ ((B) ? 1 : 0)) The ? here eliminates the problems from using larger != 1 quantities as true, as above.