Question about assignment (assignment operators)

[Michael Jones]

Oh, Great Go Gods...

From the Go language specification on Assignment:

Assignment = ExpressionList assign_op ExpressionList .

assign_op = [ add_op | mul_op ] "=" .

...and from Operators:

binary_op  = "||" | "&&" | rel_op | add_op | mul_op .

rel_op     = "==" | "!=" | "<" | "<=" | ">" | ">=" .

add_op     = "+" | "-" | "|" | "^" .

mul_op     = "*" | "/" | "%" | "<<" | ">>" | "&" | "&^" .

unary_op   = "+" | "-" | "!" | "^" | "*" | "&" | "<-" .

Thus it is no surprise that my attempt at 

b := true

:

b &&= functionReturningBoolean()

:

did not work. ;-)

However, when I went to the spec I had expected it to read this way:

Assignment = ExpressionList assign_op ExpressionList .

assign_op = [ logic_op | add_op | mul_op ] "=" .

...and from Operators:

binary_op  = logic_op | rel_op | add_op | mul_op .

logic_op    = "||" | "&&" .

rel_op     = "==" | "!=" | "<" | "<=" | ">" | ">=" .

add_op     = "+" | "-" | "|" | "^" .

mul_op     = "*" | "/" | "%" | "<<" | ">>" | "&" | "&^" .

unary_op   = "+" | "-" | "!" | "^" | "*" | "&" | "<-" .

Now my questions:

1. Why were the logic operation handled as special cases in the Operator definition?

2. Why are logical operations unwelcome as assignment operators? 

3. Any chance of considering this as change?

Thanks,

Michael

P.S. I did search through the Forum. It seems that "&&=" is challenging to search for there and in Google search. ;-)

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765

[Honza]

Dne 22.6.2012 17:50 "Michael Jones" <m...@google.com> napsal(a):

> 2. Why are logical operations unwelcome as assignment operators? 

I guess the short-cut rules of the logical opetators are the possible reason. It would be somehow surprising that in 'v &&= expr' expr might not be evaluated at all, in contrast to all other assign-ops.

?

-j

[Ian Lance Taylor]

Michael Jones <m...@google.com> writes:

> 1. Why were the logic operation handled as special cases in the Operator
> definition?

Because they short circuit, unlike the other operators.

> 2. Why are logical operations unwelcome as assignment operators?

Same answer.

> 3. Any chance of considering this as change?

I don't know. Should a &&= b always evaluate b? Because then it would
not be a syntactic shorthand for a = a && b.

Ian

[Michael Jones]

Oops. All I really wanted was "&=" and I was not thinking clearly. Sorry!

--

[Michael Jones]

Well, let me be more clear. (I'm rushing here with other matters, so I'll stop that, and say this):

Since Go has Booleans then there is use for:

a. logical AND, OR, NOT in expressions 

b. the handy short-circuit evaluation promise pioneered in C.

These are not the same thing. Clearly there are times for A & B as well as A &&B in C, C++, etc.

Go Boolean algebra has AND (&&), OR (||), and NOT (!) that only comes with both cases (a) and (b) above as a single mode.

What I wanted this morning, conceptually as I meant in the first email and stated explicitly in the second, is "result &= BoolFunc()" as opposed to "result = BoolFunc() && result." 

Both email responses were clear that if "&&" can only mean (b) above, short-circuit conditional evaluation. I'm OK with that. I only wrote that to stay in the "&& for Bools" realm. I'd be happy with "&=", especially if it were allowed for bools.

Michael

[Ian Lance Taylor]

Michael Jones <m...@google.com> writes:

> Both email responses were clear that if "&&" can only mean (b) above,
> short-circuit conditional evaluation. I'm OK with that. I only wrote that
> to stay in the "&& for Bools" realm. I'd be happy with "&=", especially if
> it were allowed for bools.

That is true, I can easily imagine supporting the &, |, ^, and &^
operators for the bool type.

Ian

[Jiří Zárevúcky]

On Friday, 22 June 2012 20:05:03 UTC+2, Michael Jones wrote:

Both email responses were clear that if "&&" can only mean (b) above, short-circuit conditional evaluation. I'm OK with that. I only wrote that to stay in the "&& for Bools" realm. I'd be happy with "&=", especially if it were allowed for bools.

If you look carefuly at the rules you mentioned above, you'll see that &= actually is in the language, because & is a multiplicative operator (bitwise logical conjunction to be precise).

Although you could argue that bitwise operators could be overloaded to work on bools, I personally don't find that idea too tasteful. I think it would add confusion to code, as you'd need more context to figure out what & means. 

[Michael Jones]

George Boole and Aristotle would be happy with that, and so would I. ;-)