V: compiling (boolean expression) ^ (boolean expression) fails

[spytheman]

V version: V 0.1.19 a555b1f
OS: Ubuntu 16.04.3 LTS

What did you do?
I tried running this program:

b := (1!=0) ^ (3!=0)
println( b )

What did you expect to see?
a) a type error, because boolean can not be bitwise xored with another boolean
b) booleans on both sides of the ^ be casted to ints, then xored bitwise, and result assigned to b

What did you see instead?

0[09:20:23] /v/v $ vlang run xor_bug.v 
xor_bug.tmp.c: In function ‘main’:
xor_bug.tmp.c:3522:25: error: expected identifier or ‘(’ before numeric constant
  bool b= ( 1 != 0 ) , ( 3 != 0 ) ;
                         ^
V error: C error. This should never happen. Please create a GitHub issue: https://github.com/vlang/v/issues/new/choose
1[09:22:52] /v/v $ 

NB: the ^ produced , in the generated C code.

[gslicer]

@giovaniandrade is right - boolean XOR has the same truth table as != for boolean operands, so another boolean XOR is not needed.

Agree with both of you obviously, I just didn't try if that works and maybe it could be documented as such in the Docs ;)

[ghost]

!= behaves as xor for booleans already. Although the meaning is a bit obscured, I suppose.

[dumblob]

I think you should not be able to "cast" a boolean to an int as logical type values are not numeric per se (maybe in C they are mostly modelled as 0/1=false/true but you could have 0/-1, 1/-1, or whatever) as e.g. 0 can be a true result in some cases and 1 can be the false answer, it just does not make sense to have bitwise operators for the binary representation or "true" or "false", which can be whatever.

I'd support this under one condition - namely that it'll be possible to efficiently compile stuff like this:

x := -99  // my representation of "true"
y := if x == 0 { false } else { true }

By efficiently I would expect something like this in C:

int x = -99;
int y = x;  // possible because semantics of the above "ternary"
            // if-statement matches C semantics

or in the worst case:

int x = -99;
int y = ! ! x;

This efficiency becomes more important when one starts working with huge number of bits (using e.g. bitsets, integer compression techniques, etc.) where it does matter a lot how many instructions one bit operation comprises of.

From my experience though it's way more difficult to find such patterns and optimize them then just precisely define casting from i8/u8, i16/u16, ... to bool in the language specification, enforce this precise definition, and leave the programmer with all the power.

[spytheman]

The problem is that right now, the current behavior is to generate invalid C code, that does not make sense at all (generating 2 expressions separated by a comma).
A V type error would be better than that in my opinion.

[spytheman]

@giovaniandrade is right - boolean XOR has the same truth table as != for boolean operands, so another boolean XOR is not needed.

[medvednikov]

Fixed: operator ^ not defined on bool

[medvednikov]

Same with & and |