Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remove the ++ and –- operators

github.com

Post reply on HN
Print view View original

241–249 of 249 posts

Re: Remove the ++ and –- operators

#241

Post by Veedrac »

dbpokorny wrote: post #234
Veedrac wrote: post #221

Earlier quoted context omitted.

> 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…

> The only time you should actually override __iadd__ is for mutable objects What would the rationale be for such a rule? the docs don't mention anything like that https://docs.python.org/2/library/operator.html and I've never heard it before. In Python, neither integers nor strings are mutable and both support the "x += y" syntax. The __iadd__ method works the same for both mutable and immutable objects AFAIK

> What would the rationale be for such a rule?

Because __iadd__ automatically delegates to __add__. For immutable objects that's the best you can do, so there's no reason to write both.

Re: Remove the ++ and –- operators

#242

Post by kuschku »

y4mi wrote: post #224
kuschku wrote: post #75

Earlier quoted context omitted.

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.

Yes – but that’s still [Shift]+['] and then [Space]

Re: Remove the ++ and –- operators

#243

Post by marcosdumay »

WorldMaker wrote: post #229
marcosdumay wrote: post #222

Earlier quoted context omitted.

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 th…

What?

I was talking about my statement at the upper comment. I used x++ there, not ++x. The doubt is about the value of the other x.

The difference you talk is about the main behavior of the operators. You won't find any description of them that does not state it.

Re: Remove the ++ and –- operators

#244

Post by homulilly »

myth_buster wrote: post #66
homulilly wrote: post #36

I strongly disagree with this. Being able to do a very simple task like increment or decrement a number inline is useful and reduces clutter and I've always found the idea that the operator complicates things ridiculous. The way they work has always been obvious to me since I first learned to program in PHP as a tween.

I've always found the idea that the operator complicates things ridiculous Given that there are interview questions on the behavior of post/pre increment operators shows that there is some subtlety to it which creates ambiguity and complexity. So given that they want the language to be accessible, it makes sense to reduce ambiguity.

Seems more like an idiot test to me. If someone legitimately finds something this basic confusing they are going to constantly be running into problems and aren't suited for a programming job.

Re: Remove the ++ and –- operators

#245

Post by LBarret »

JoeAltmaier wrote: post #227
jbert wrote: post #223

Earlier quoted context omitted.

> 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.

why ? Could you elaborate ?

Because from my point of view, it could be only the case only if the scopes are weak or underused, or names are bad (too short, ect). After SSA is all about one-use names.

Re: Remove the ++ and –- operators

#246

Post by WorldMaker »

marcosdumay wrote: post #243
WorldMaker wrote: post #229

Earlier quoted context omitted.

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 th…

What? I was talking about my statement at the upper comment. I used x++ there, not ++x. The doubt is about the value of the other x. The difference you talk is about the main behavior of the operators. You won't find any description of them that does not state it.

Well, I made the wrong assumption in what was being asked then, I guess. I would presume the "left to right" rule is more generally assumed knowledge in C/C++ than postfix/prefix distinction of ++/-- which are pretty much the only unary operators with such a distinction in the language, whereas "left to right" is a rather underlying general rule and one in which you generally assume people are familiar with.

My apologies for answering the wrong question, but yes in that case the standard is also mostly clear that you can assume that things are evaluated from left to right in C/C++ and thus the first x in the line should be evaluated prior to the x++ later in the line...

Re: Remove the ++ and –- operators

#247

Post by marcosdumay »

marcosdumay wrote: post #222
yokohummer7 wrote: post #219

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.

Just to update, yes, it's undefined behavior.

Every compiler seems to act the same way today, but some specs oriented optimizer might play havoc with that line.

Re: Remove the ++ and –- operators

#248

Post by jbert »

JoeAltmaier wrote: post #227
jbert wrote: post #223

Earlier quoted context omitted.

> 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.

I disagree. Names are comments. You don't want more mutable state across large scopes, but using intermediate names can help comprehension.

Re: Remove the ++ and –- operators

#249

Post by imdsm »

dragonwriter wrote: post #93
imdsm wrote: post #85

> Keep both x++ and ++x in the language, even though they do the same thing. ?

> > Keep both x++ and ++x in the language, even though they do the same thing. > ? That was a subalternative underneath the alternative of changing the operators to return Void like other assignment operators. ++x and x++ differ in that the former returns the value after the increment, the latter the value before; if they return void, all they do is the increment with no difference.

This a delayed response for which I apologise, but thank you for yours, this makes complete sense now. I must have missed this at the time. Makes sense now.
Post reply on HN