Live data from Hacker News

Remove the ++ and –- operators

github.com

221–230 of 249 posts

Re: Remove the ++ and –- operators

#221

Earlier quoted context omitted.

Looking at eliteraspberrie's example, not really. Python's __iadd__ and such are not able to reassign. There is no "inout" in Python. The assignment aspect of __iadd__ is done through self mutation (and an extra hard-coded assignment to support immutable variables).

The assignment aspect of __iadd__ is done like any other assignment in python. The one to one equivalent of eliteraspberrie's would be: class Vector2D: def __iadd__(self, other) return self + other No "self mutation" as you suggest. a += b is equivalent to a = a.__iadd__(b)

> No "self mutation" as you suggest.

Your example would be the implementation for immutable Vector2Ds, and is implemented for you if you just wrote __add__. (I presume object.__iadd__ falls back to self.__add__.)

The only time you should actually override __iadd__ is for mutable objects, in which case it should look more like

  class Vector2D:
      def __iadd__(self, other)
          for i, x in enumerate(other):
              self[i] += x
          return self
That's the self mutation I was talking about.

Well, strictly that's not OK either, since operators shouldn't be duck-typed. Instead you should do

  class Vector2D:
      def __iadd__(self, other)
          if not isinstance(other, Vector2D):
              return NotImplemented

          for i, x in enumerate(other):
              self[i] += x
          return self

Re: Remove the ++ and –- operators

#222

Earlier quoted context omitted.

Oh, I've just closed a Haskell window, saw the title and thought "how would I concatenate strings?", but I'm digressing... But no, not only for for(;;). There's also the too common array traversal: while(something) a[x] = b[x++]; And lots and lots of ugly but useful uses in pointer arithmetics where they make things clear. They have no place in any other language, but I'd really miss both operators in C.

> while(something) a[x] = b[x++]; Wait, isn't this an undefined behavior? Is the order of evaluations of `x` in the left side and `x++` in the right side defined? I'm always confused at things like this!

I dunno. I always thought the ++ operator was evaluated after the entire statement, and every compiler that I could get my hands on behaved that way.

But, well, the specs are another matter entirely.

Re: Remove the ++ and –- operators

#223
post #72

Earlier quoted context omitted.

Is there a significant benefit to this over using a new name for the result? y = (x + 1) / atan(x) - x; x = y; // If you're in a loop and updating some value If would hope/imagine that a compiler could reduce the two to the same code - and I don't think it reads any worse. Is there a downside beyond the extra line of code?

To be clear: the assignment isn't the optimization; its the use of a symbol for 'x' on the rhs so that the compiler can recognize it. To illustrate that X &x = { complex reference expression for x } y = (x + 1) / atan(x) - x; Now the compiler has the clues it needs to write good code. And with language support I don't have to introduce new names for each occurrence; just one name like that readers can quickly learn.

> And with language support I don't have to introduce new names for each occurrence;

Having as a name is only useful I think if you don't want to give it another name? I was asking what's the downside of giving it a name.

Re: Remove the ++ and –- operators

#224
post #75
post #3

Earlier quoted context omitted.

I think I'd argue with the "not much shorter" because it's less typing to perform a `++` versus `+=1`; I hold shift, I type the = key, obtaining the +, then I have to pause typing long enough to release the shift key, type the = key again, and now my other hand has to get involved and type a 1. And that's without the spaces.

Well, I type the * key to get a +, then shift and 0 to get a =, then 1 to get a 1. Slow, and my fingers have to jump completely over the keyboard. What is far more annoying, and should be banned, are `these` (I have to press shift+' twice to get one `, otherwise I end up with á' instead of `a`), and {}[], as they are on AltGr+7/8/9/0

cant you use `+space to type one? it always worked for me with all keymaps... was awkward the first few times, but by now its become really easy.

Re: Remove the ++ and –- operators

#225

Earlier quoted context omitted.

I think forcing me to use "+=" in Ruby reminds me that it's really a method call (which can be overridden), rather than an increment operation on primitive types.

Yes, this exactly! While rarely a good idea, it does give you super powers when dealing with specialized libraries, or when writing your own :)

Have you ever written a container (with an iterator)?

Re: Remove the ++ and –- operators

#226
post #105

> Their expressive advantage is minimal - x++ is not much shorter than x += 1 Personal opinion, but I definitely miss '++' every time I'm doing '+=' in Python.

Then I take it you don't buy into the Python philosophy of "There should be one-- and preferably only one --obvious way to do it." https://www.python.org/dev/peps/pep-0020/

Neither does Python. For example, % operator and .format().

Re: Remove the ++ and –- operators

#227
post #223

Earlier quoted context omitted.

To be clear: the assignment isn't the optimization; its the use of a symbol for 'x' on the rhs so that the compiler can recognize it. To illustrate that X &x = { complex reference expression for x } y = (x + 1) / atan(x) - x; Now the compiler has the clues it needs to write good code. And with language support I don't have to introduce new names for each occurrence; just one name like that readers can quickly learn.

> And with language support I don't have to introduce new names for each occurrence; Having as a name is only useful I think if you don't want to give it another name? I was asking what's the downside of giving it a name.

Name proliferation is a famous issue. One-use names are evil.

Re: Remove the ++ and –- operators

#228

Earlier quoted context omitted.

From Swift documentation: for i in 0.. This ..< operator is so much more logical, of course! Not to mention == and ===. Logically, the first one compares twice and the second compares three times (for luck), just in case first two comparisons didn't go through...

I would implement that like: zip(names, 1...names.count).forEach { name, index in print("Person \(index) is called \(name)") } Or, in an ideal world: zip(names, 1...names.count) .map({ name, index in "Person \(index) is called \(name)" }) .forEach(print) Currently, that isn't valid Swift, "print" can't be used like that, though if you define a closure it works: let printIt = { x in print(x) } zip(names, 1...names.cou…

My argument ultimately "there are better things to do". At the same time, interpreting ++ as add-add is certainly not an argument. You can say that you don't like infix and postfix operators, but not whether they are readable.

If you consider readability, then why !a instead of not(a)? Why || instead of or?

Re: Remove the ++ and –- operators

#229

Earlier quoted context omitted.

> while(something) a[x] = b[x++]; Wait, isn't this an undefined behavior? Is the order of evaluations of `x` in the left side and `x++` in the right side defined? I'm always confused at things like this!

I dunno. I always thought the ++ operator was evaluated after the entire statement, and every compiler that I could get my hands on behaved that way. But, well, the specs are another matter entirely.

Hah, just this sort of confusion is part of the proposal to drop ++ and -- from Swift.

x++ returns x and then increments it, so yes the spec agrees with your intuition here.

Whereas ++x increments x and then returns the incremented x.

That subtle difference between x++ and ++x has been the debugging nightmare of many a C developer over the years. It's also why there's a fun irony in the C++ name and why people say the actual successor to C will be ++C.

Re: Remove the ++ and –- operators

#230

Earlier quoted context omitted.

Apple has a long history of readability over terseness. "plus plus" doesn't mean anything. It might even be confusing that it doesn't add 2 .

From Swift documentation: for i in 0.. This ..< operator is so much more logical, of course! Not to mention == and ===. Logically, the first one compares twice and the second compares three times (for luck), just in case first two comparisons didn't go through...

Speaking as somebody who has no idea what X..I wonder what somebody who had no idea about X++ would guess it meant? Based on my daily conversations, if I didn't know already, I would guess it means "variable X has done a good job and deserves some IRC karma"...
Post reply on HN