4 ms·

Moving away from? Ambiguity? Maybe from "x++", and even that is not clear. There is no ambiguity, "++x" is as strong as ever in the C family including C, C++,

Moving away from? Ambiguity? Maybe from "x++", and even that is not clear. There is no ambiguity, "++x" is as strong as ever in the C family including C, C++, C#, Java, JavaScript. Python added "x+=1" which is as ambiguous as "++x" and did so (relatively) recently, even though it had "x=x+1". I'm not sure why you think "programming languages are moving away from the ++ operator". Care to elaborate?

ivanhoe 6y ago
Not that I ever had problem with it, but ambiguity with ++ lies in prefix/postfix version of the operator. I don't see how x+=1 is ambiguous in any way, it's just a shorter way to write it, but there's no side-effects like with x++?
- beagle3 6y ago
  There is no ambiguity. Prefix is increment pre (increment before getting the value). Postfix is increment post (increment after getting the value). Both have side effects as does x+=1. consider the call f(x+=1,x+=1) when x=5; what is the call? f(6,7) or f(7,6)? Iirc even f(6,6) and f(7,7) were valid behavior in the past.
  - ptx 6y ago
    "x += 1" in Python is a statement, not an expression, so that's a SyntaxError. But I suppose you would run into this kind of ambiguity with the walrus operator, i.e. >>> x = 5 >>> f = lambda a, b: (a, b) >>> print(f(x := x + 1, x := x + 1)) (6, 7) PEP 572 appears[1] to specify that the evaluation order should always be left to right. [1] https://www.python.org/dev/peps/pep-0572/#change-to-evaluation-order https://www.python.org/dev/peps/pep-0572/#change-to-evaluati...
aldanor 6y ago
If you know C++, do you also know that `a[i] = i++` is UB... but only until C++17? If not, I hope that answers the question. That's one of the reasons some newer languages like Rust purposefully avoided increment operators, where instead you just do `x += 1` (and the add-assign operator doesn't return anything) or `x = x + 1`.
- beagle3 6y ago
  C has lots of undefined behavior unrelated to ++ (which only adds a small twist in the grand scheme of things). In C afaik f(g(),h()) is still UB because either g() or h() could be called first. ++ is just another small detail. (And no, I didn’t know C++17 made that behavior defined. Do you have a quick description of how it is defined now?) “Newer languages like rust” - just say “rust”, unless you have another good example of a non fringe language that adopted most c syntax including += but without ++.
  - bregma 6y ago
    `f(g(),h())` is not UB. The order of evaluation of parameters is unspecified, but it's not undefined. They will be evaluated in some order before the call to `f()` takes place. If both functions modify the same global state, the order of modification is unspecified. It's still not undefined, and your use of global variables is still not recommended.
  - gonzus 6y ago
    Zig did too.
cinntaile 6y ago
I didn't mean to say that old languages would change the behavior of well established operators, that seems unlikely to happen and would be quite bad for backwards compatibility. Newer languages, like Rust and Go (although they went with a different solution [0]) but probably others as well don't want to deal with the ambiguity of post- or pre-increment operators. Python as well as you mentioned. From your other replies I see that you don't agree that there is any ambiguity. That is fine with me, I don't plan on trying to convince you. I lack the in-depth knowledge to be able to do that in a credible way anyway. I just note that the designers of newer languages seem to disagree with your conclusion. [0] https://golang.org/doc/faq#inc_dec https://golang.org/doc/faq#inc_dec
ptx 6y ago
> Python added "x+=1" ... (relatively) recently Not all that recently anymore – it was added 20 years ago in Python 2.0: https://docs.python.org/2/whatsnew/2.0.html#augmented-assignment https://docs.python.org/2/whatsnew/2.0.html#augmented-assign... But the walrus operator, "x := x + 1", was added very recently: https://docs.python.org/3/whatsnew/3.8.html#assignment-expressions https://docs.python.org/3/whatsnew/3.8.html#assignment-expre...

ivanhoe 6y ago

Not that I ever had problem with it, but ambiguity with ++ lies in prefix/postfix version of the operator. I don't see how x+=1 is ambiguous in any way, it's just a shorter way to write it, but there's no side-effects like with x++?

beagle3 6y ago
There is no ambiguity. Prefix is increment pre (increment before getting the value). Postfix is increment post (increment after getting the value). Both have side effects as does x+=1. consider the call f(x+=1,x+=1) when x=5; what is the call? f(6,7) or f(7,6)? Iirc even f(6,6) and f(7,7) were valid behavior in the past.
- ptx 6y ago
  "x += 1" in Python is a statement, not an expression, so that's a SyntaxError. But I suppose you would run into this kind of ambiguity with the walrus operator, i.e. >>> x = 5 >>> f = lambda a, b: (a, b) >>> print(f(x := x + 1, x := x + 1)) (6, 7) PEP 572 appears[1] to specify that the evaluation order should always be left to right. [1] https://www.python.org/dev/peps/pep-0572/#change-to-evaluation-order https://www.python.org/dev/peps/pep-0572/#change-to-evaluati...

aldanor 6y ago

If you know C++, do you also know that `a[i] = i++` is UB... but only until C++17? If not, I hope that answers the question. That's one of the reasons some newer languages like Rust purposefully avoided increment operators, where instead you just do `x += 1` (and the add-assign operator doesn't return anything) or `x = x + 1`.

beagle3 6y ago
C has lots of undefined behavior unrelated to ++ (which only adds a small twist in the grand scheme of things). In C afaik f(g(),h()) is still UB because either g() or h() could be called first. ++ is just another small detail. (And no, I didn’t know C++17 made that behavior defined. Do you have a quick description of how it is defined now?) “Newer languages like rust” - just say “rust”, unless you have another good example of a non fringe language that adopted most c syntax including += but without ++.
- bregma 6y ago
  `f(g(),h())` is not UB. The order of evaluation of parameters is unspecified, but it's not undefined. They will be evaluated in some order before the call to `f()` takes place. If both functions modify the same global state, the order of modification is unspecified. It's still not undefined, and your use of global variables is still not recommended.
- gonzus 6y ago
  Zig did too.

cinntaile 6y ago

I didn't mean to say that old languages would change the behavior of well established operators, that seems unlikely to happen and would be quite bad for backwards compatibility. Newer languages, like Rust and Go (although they went with a different solution [0]) but probably others as well don't want to deal with the ambiguity of post- or pre-increment operators. Python as well as you mentioned. From your other replies I see that you don't agree that there is any ambiguity. That is fine with me, I don't plan on trying to convince you. I lack the in-depth knowledge to be able to do that in a credible way anyway. I just note that the designers of newer languages seem to disagree with your conclusion. [0] https://golang.org/doc/faq#inc_dec https://golang.org/doc/faq#inc_dec

ptx 6y ago

> Python added "x+=1" ... (relatively) recently Not all that recently anymore – it was added 20 years ago in Python 2.0: https://docs.python.org/2/whatsnew/2.0.html#augmented-assignment https://docs.python.org/2/whatsnew/2.0.html#augmented-assign... But the walrus operator, "x := x + 1", was added very recently: https://docs.python.org/3/whatsnew/3.8.html#assignment-expressions https://docs.python.org/3/whatsnew/3.8.html#assignment-expre...