4 ms·

I'm surprised they removed x++ from the language. This is always a big frustration when I'm writing Python code.

kinofcain 11y ago
Rust did too. There's probably a pie chart somewhere of time lost to having to type out "foo += 1" vs number of hours lost to people screwing up operator precedence for foo++ or ++foo. (EDIT: as munificent points out this is actually a combination of operator precedence and sequence points) The pie chart is probably severely lopsided. EDIT: Since the main problem is the precedence of the post increment/decrement operator, I would have preferred to see them get rid of that one and keep ++foo but overall not much of a loss. At least they didn't get rid of the ternary operator like Go did...
- mmastrac 11y ago
  If anything it would be time lost to accidentally typing ++x instead of x++. I always found the precedence to be pretty intuitive in C (unary ops generally bind tightest). The only time you'd have to Google is if you were doing something weird like `-(x++)`. I'm also willing to accept that I'm old, stubborn, and unhappy about changing my ways and that this is the future... :)
  - kinofcain 11y ago
    See I always thought most people who wrote foo++ actually meant ++foo and it typically only came up when the operator precedence made the two not equivalent, causing a subtle bug. I can't even think of a time where I really needed a use-then-increment operator where I wouldn't have just used the value, then incremented it on the next line anyway (maybe even with a post-increment out of habit).
    - mmastrac 11y ago
      Interesting. I generally choose x++ for the majority of array-striding code I write, and usually as a shortcut to avoid having a bunch of x++ lines scattered around. I've found that you can structure your code either way and postfix seems to be easier to reason over for me. I use ++x very infrequently, and mainly in hand-written text parsers.
      - sbmassey 11y ago
        I generally assume that ++x is idiomatic in c++, and x++ in c, because in c++ you may be calling against some non-primitive type, where the update-and-return-the-non-updated-value semantics of the postfix version are not optimisable away.
      - kinofcain 11y ago
        Well, I guess we're both going to do it the same way in swift 3, which is probably the whole point...
    - stormbrew 11y ago
      int arr[5]; int i = 0; while (shouldIKeepGoing() && i < 5) arr[i++] = getAThing(); If you use ++i there you'll skip 0 and overflow the array. This is what the postfix form is for, if you value terseness. Edit: To clarify, I'm not necessarily saying you don't know that's what it's for, but this is a pattern I see pretty frequently in the wild so I'm just throwing it out there with an explanation of why people find value in it.
  - boulos 11y ago
    I generally agree, except in the case of more than one per statement / expression as munificent pointed out above. What does: int x = 0; printf("%d %d", x++, x++); print? Is that true for all systems and compilers? (Answer: nope!).
- munificent 11y ago
  It's not about operator precedence, it's about sequence points. Assignment—including in ++—is a side-effecting operation. An expression form that does side effects can lead to very confusing code like: foo(a++, a++); What values get passed foo()? In some languages, it's undefined (!). In others, there is a well-defined answer, but even there the answer may not be intuitive. Removing assignment expression forms avoids this. Note that even "=" is a statement in Go. It does sacrifice a little expressiveness. But in languages that have dedicated syntax like ranges for iterating over sequential numbers, the ++ and -- operators end up pretty rarely used so it's no big loss.
  - masklinn 11y ago
    > Note that even "=" is a statement in Go. In Python and Rust as well.
    - dbaupp 11y ago
      Nitpicking: assignment is an expression that returns () in Rust, meaning `foo(a = 1, a)` is valid if foo has a signature like `fn foo(x: (), y: i32)`. However, arguments are (mostly) defined to be evaluated from left to right.
  - kinofcain 11y ago
    Yes, sorry, I should have said sequence points also.
  - andy_ppp 11y ago
    In my opinion the example given is awful code, yes we should protect developers from themselves but good taste in code is important and incrementing a counter easily should still be a thing. Just stop the bad cases then rather than the well understood and expected usage.
  - bjz_ 11y ago
    > It does sacrifice a little expressiveness. But in languages that have dedicated syntax like ranges for iterating over sequential numbers, the ++ and -- operators end up pretty rarely used so it's no big loss. This is one of the big points too, that often gets overlooked. The removal of ++ fits nicely with the removal of C-style for loops.
- saturncoleus 11y ago
  If you don't care about side effects: C: int foo = bar ? 2 : 4; Go: foo := map[bool]int{true:2, false:4}[bar] Python had a similar trick before 2.5 added ternary conditionals.
rnnr 11y ago
yeah, it was such a great question for coding exams at college, what is the difference between x++ and ++x? It also helped you write smellier code, with the exception of using it in for..loops' 'signature definition'. For...loops in swift and generally elsewhere are being superseded by for...each loops like python's(and other languages)
coupdejarnac 11y ago
Just include this somewhere in your codebase. Maybe I'll make this more robust. postfix operator ++{} postfix func ++(lhs:Int) -> Int { return lhs + 1 }
- valleyer 11y ago
  That implementation is wrong in multiple ways. First of all, it should return the pre-increment value. Second, it doesn't actually increment your variable (you need to use an `inout` parameter for that). Perhaps this demonstrates perfectly why it's being removed!
  - coupdejarnac 11y ago
    Yes, indeed. I wrote this somewhat as a joke, and I hope nobody would actually do this in production.
bjz_ 11y ago
You should be hiding naked mutation/accumulation like that in some abstraction. ++ is a smell that alerts you to the fact that you should probably be thinking in a different way.

Rust did too. There's probably a pie chart somewhere of time lost to having to type out "foo += 1" vs number of hours lost to people screwing up operator precedence for foo++ or ++foo. (EDIT: as munificent points out this is actually a combination of operator precedence and sequence points) The pie chart is probably severely lopsided. EDIT: Since the main problem is the precedence of the post increment/decrement operator, I would have preferred to see them get rid of that one and keep ++foo but overall not much of a loss. At least they didn't get rid of the ternary operator like Go did...

mmastrac 11y ago
If anything it would be time lost to accidentally typing ++x instead of x++. I always found the precedence to be pretty intuitive in C (unary ops generally bind tightest). The only time you'd have to Google is if you were doing something weird like `-(x++)`. I'm also willing to accept that I'm old, stubborn, and unhappy about changing my ways and that this is the future... :)
- kinofcain 11y ago
  See I always thought most people who wrote foo++ actually meant ++foo and it typically only came up when the operator precedence made the two not equivalent, causing a subtle bug. I can't even think of a time where I really needed a use-then-increment operator where I wouldn't have just used the value, then incremented it on the next line anyway (maybe even with a post-increment out of habit).
  - mmastrac 11y ago
    Interesting. I generally choose x++ for the majority of array-striding code I write, and usually as a shortcut to avoid having a bunch of x++ lines scattered around. I've found that you can structure your code either way and postfix seems to be easier to reason over for me. I use ++x very infrequently, and mainly in hand-written text parsers.
    - sbmassey 11y ago
      I generally assume that ++x is idiomatic in c++, and x++ in c, because in c++ you may be calling against some non-primitive type, where the update-and-return-the-non-updated-value semantics of the postfix version are not optimisable away.
    - kinofcain 11y ago
      Well, I guess we're both going to do it the same way in swift 3, which is probably the whole point...
  - stormbrew 11y ago
    int arr[5]; int i = 0; while (shouldIKeepGoing() && i < 5) arr[i++] = getAThing(); If you use ++i there you'll skip 0 and overflow the array. This is what the postfix form is for, if you value terseness. Edit: To clarify, I'm not necessarily saying you don't know that's what it's for, but this is a pattern I see pretty frequently in the wild so I'm just throwing it out there with an explanation of why people find value in it.
- boulos 11y ago
  I generally agree, except in the case of more than one per statement / expression as munificent pointed out above. What does: int x = 0; printf("%d %d", x++, x++); print? Is that true for all systems and compilers? (Answer: nope!).
munificent 11y ago
It's not about operator precedence, it's about sequence points. Assignment—including in ++—is a side-effecting operation. An expression form that does side effects can lead to very confusing code like: foo(a++, a++); What values get passed foo()? In some languages, it's undefined (!). In others, there is a well-defined answer, but even there the answer may not be intuitive. Removing assignment expression forms avoids this. Note that even "=" is a statement in Go. It does sacrifice a little expressiveness. But in languages that have dedicated syntax like ranges for iterating over sequential numbers, the ++ and -- operators end up pretty rarely used so it's no big loss.
- masklinn 11y ago
  > Note that even "=" is a statement in Go. In Python and Rust as well.
  - dbaupp 11y ago
    Nitpicking: assignment is an expression that returns () in Rust, meaning `foo(a = 1, a)` is valid if foo has a signature like `fn foo(x: (), y: i32)`. However, arguments are (mostly) defined to be evaluated from left to right.
- kinofcain 11y ago
  Yes, sorry, I should have said sequence points also.
- andy_ppp 11y ago
  In my opinion the example given is awful code, yes we should protect developers from themselves but good taste in code is important and incrementing a counter easily should still be a thing. Just stop the bad cases then rather than the well understood and expected usage.
- bjz_ 11y ago
  > It does sacrifice a little expressiveness. But in languages that have dedicated syntax like ranges for iterating over sequential numbers, the ++ and -- operators end up pretty rarely used so it's no big loss. This is one of the big points too, that often gets overlooked. The removal of ++ fits nicely with the removal of C-style for loops.
saturncoleus 11y ago
If you don't care about side effects: C: int foo = bar ? 2 : 4; Go: foo := map[bool]int{true:2, false:4}[bar] Python had a similar trick before 2.5 added ternary conditionals.

rnnr 11y ago

yeah, it was such a great question for coding exams at college, what is the difference between x++ and ++x? It also helped you write smellier code, with the exception of using it in for..loops' 'signature definition'. For...loops in swift and generally elsewhere are being superseded by for...each loops like python's(and other languages)

coupdejarnac 11y ago

Just include this somewhere in your codebase. Maybe I'll make this more robust. postfix operator ++{} postfix func ++(lhs:Int) -> Int { return lhs + 1 }

valleyer 11y ago
That implementation is wrong in multiple ways. First of all, it should return the pre-increment value. Second, it doesn't actually increment your variable (you need to use an `inout` parameter for that). Perhaps this demonstrates perfectly why it's being removed!
- coupdejarnac 11y ago
  Yes, indeed. I wrote this somewhat as a joke, and I hope nobody would actually do this in production.

bjz_ 11y ago

You should be hiding naked mutation/accumulation like that in some abstraction. ++ is a smell that alerts you to the fact that you should probably be thinking in a different way.