9 ms·

Edit: This is obviously a bug and needs to be fixed. My post is more about how the syntax "+=" is usually explained as shorthand for "x = x + 1" (https://www.tu

Edit: This is obviously a bug and needs to be fixed. My post is more about how the syntax "+=" is usually explained as shorthand for "x = x + 1" (https://www.tutorialspoint.com/java/java_basic_operators.htm https://www.tutorialspoint.com/java/java_basic_operators.htm), when it's not strictly true (depends on what's in "x"). "+=" is [usually explained as] shorthand for repeating the left side. Why should > foo[i++] += 1 evaluate differently than > foo[i++] = foo[i++] + 1 ? The way it currently works is the way I would expect it to work, but I'm evidently in the minority here. I also don't write Java and since this is a change from Java 8, it needs to be fixed. Let me state that again: yes, of course this bug needs to be fixed.

lotyrin 8y ago
I understand this point and it's true that there would be some elegance if both statements were equivalent but I see greater utility without that equivalence: Rather than a redundancy and sugar on + and = ("I do not want to type the left side twice"), it is a distinction I am making to the compiler ("I do not want you to evaluate the left side twice").
jjnoakes 8y ago
> The way it currently works is arguably the way it should work, irrespective of the spec. The spec is how it should work, regardless of developer's opinions. > Why should [a] evaluate differently than [b]? In my opinion (and I'm guessing in the opinion of the spec authors, though I can't be sure), saying "x += y" means "add y to x", so I'd expect the language to: 1) Figure out what "x" is once 2) Add "y" to it Your opinion seems to be that saying "x += y" means "desugar to x = x + y" and you expect the language to: 1) Figure out what "x" is as a value 2) Add "y" to the value of "x" 3) Figure out what "x" is as a location (which may differ from 1) 4) Store the result into "x" To me step 3 is very surprising, that "x" may differ, which is why I think the spec's definition is the more intuitive one (plus, it doesn't require knowledge of "desugaring" things).
- deleted 8y ago
  [deleted]
civilitty 8y ago
They're not the same thing semantically, even though the final x86/64 assembly might be the same after a compiler is done with it. '+' is addition but '+=' is addition "in place" which means that the calculation is performed in the location where it will be stored (although, again, these might look identical when talking about register allocation and whatnot in the final assembly). This is relevant to reordering compilers because it allows them to do certain optimizations that are normally hard to prove safe because of aliasing rules, especially in lower level intermediate forms where typing and other information might be lost.
Dylan16807 8y ago
Would you also argue that min(foo(), bar()) should evaluate one of the functions twice? When you explain the definition as "(a < b) ? a : b" it's only natural, even though such a macro is an infamously wrong way to implement min.

lotyrin 8y ago

I understand this point and it's true that there would be some elegance if both statements were equivalent but I see greater utility without that equivalence: Rather than a redundancy and sugar on + and = ("I do not want to type the left side twice"), it is a distinction I am making to the compiler ("I do not want you to evaluate the left side twice").

jjnoakes 8y ago

> The way it currently works is arguably the way it should work, irrespective of the spec. The spec is how it should work, regardless of developer's opinions. > Why should [a] evaluate differently than [b]? In my opinion (and I'm guessing in the opinion of the spec authors, though I can't be sure), saying "x += y" means "add y to x", so I'd expect the language to: 1) Figure out what "x" is once 2) Add "y" to it Your opinion seems to be that saying "x += y" means "desugar to x = x + y" and you expect the language to: 1) Figure out what "x" is as a value 2) Add "y" to the value of "x" 3) Figure out what "x" is as a location (which may differ from 1) 4) Store the result into "x" To me step 3 is very surprising, that "x" may differ, which is why I think the spec's definition is the more intuitive one (plus, it doesn't require knowledge of "desugaring" things).

deleted 8y ago
[deleted]

civilitty 8y ago

They're not the same thing semantically, even though the final x86/64 assembly might be the same after a compiler is done with it. '+' is addition but '+=' is addition "in place" which means that the calculation is performed in the location where it will be stored (although, again, these might look identical when talking about register allocation and whatnot in the final assembly). This is relevant to reordering compilers because it allows them to do certain optimizations that are normally hard to prove safe because of aliasing rules, especially in lower level intermediate forms where typing and other information might be lost.

Dylan16807 8y ago

Would you also argue that min(foo(), bar()) should evaluate one of the functions twice? When you explain the definition as "(a < b) ? a : b" it's only natural, even though such a macro is an infamously wrong way to implement min.