No increment operator (++) in Ruby?

Question

Possible Duplicate:
Why doesn't Ruby support i++ or i— for fixnum?

Why is there no increment operator in Ruby?

e.g.

i++
++i

Is the ++ operator used for something else? Is there a real reason for this?

Solution 1

Ruby has no pre/post increment/decrement operator. For instance, x++ or x-- will fail to parse. More importantly, ++x or --x will do nothing! In fact, they behave as multiple unary prefix operators: -x == ---x == -----x == ...... To increment a number, simply write x += 1.

Taken from "Things That Newcomers to Ruby Should Know " (archive, mirror)

That explains it better than I ever could.

EDIT: and the reason from the language author himself (source):

1. ++ and -- are NOT reserved operator in Ruby.
2. C's increment/decrement operators are in fact hidden assignment. They affect variables, not objects. You cannot accomplish assignment via method. Ruby uses +=/-= operator instead.
3. self cannot be a target of assignment. In addition, altering the value of integer 1 might cause severe confusion throughout the program.

Solution 2

From a posting by Matz:

(1) ++ and -- are NOT reserved operator in Ruby.

(2) C's increment/decrement operators are in fact hidden assignment. They affect variables, not objects. You cannot accomplish assignment via method. Ruby uses +=/-= operator instead.

(3) self cannot be a target of assignment. In addition, altering the value of integer 1 might cause severe confusion throughout the program.

                      matz.

Solution 3

I don't think that notation is available because—unlike say PHP or C—everything in Ruby is an object.

Sure you could use $var=0; $var++ in PHP, but that's because it's a variable and not an object. Therefore, $var = new stdClass(); $var++ would probably throw an error.

I'm not a Ruby or RoR programmer, so I'm sure someone can verify the above or rectify it if it's inaccurate.

Comments

[user1066101]

What's "REAL"? Can you define "REAL reason" in a way that's not argumentative and subjective?

[Konrad Rudolph]

Check your terminology … “auto increment” is something completely different. What you have there is a simple increment operator.

[mikej]

I agree with @Kondrad, this is just increment rather than auto increment (or preincrement and postincrement if you need to disambiguate the two.) Also it is an operator rather than an operand. I will make edits to the question to tidy this up. I hope that is OK.

[Sam Eaton]

This duplicate has more up-votes than the original.

[Donal Fellows]

Surely they could be methods on the variable object…?

[mikej]

@Donal if you mean, could they be retrospectively be added to the language without breaking things then I don't think they could. x = a++b parses as x = a + (+b) so if we had just x++ then Ruby expects another operand. This is why you tend to get syntax errors if you try to use ++ at the moment as Ruby takes part of the next statement as the operand. += is implemented as call + on the receiver passing the RHS as a parameter and then assign the value returned by + to the variable.

[Jörg W Mittag]

@Donal Fellows: variables aren't objects in Ruby.

[Donal Fellows]

I know they can't be done syntactically without breaking backward compatibility, and I think that Matz is right not to do them, but the argument that increment can't be done because of hidden assignment is in general wrong. If variables are objects then increment is naturally a method on the class of variables. Don't know if such a concept sits well with Ruby's model of the world. :-)

[Jörg W Mittag]

@Donal Fellows: But variables aren't objects in Ruby, that's why post-increment can't be implemented as a method on variable objects.

[Donal Fellows]

@Jörg: I'm not claiming that they are. Just pointing out that if they were, then you'd be able to do cool stuff. (I have no idea how that would work syntactically; I was thinking purely at the high-level semantics level. Smug Smalltalk Weenies would probably laugh at this discussion.)

[oligan]

It's valid with respect to this question, but I wish "Things That Newcomers to Ruby Should Know." was updated to reflect Ruby 1.9.

[Johntron]

Regarding point #3, since most things are objects, imagine if Ruby allowed you to do this: 1++ 1+2 # Would not be 3!

[Steve Midgley]

I feel like arguing that 1++ means we shouldn't have the ++ operator at all suggests that 1+=1 is similarly bad and therefore we shouldn't have += either, but we do. So there must be a deeper reason that Matz didn't include it. Maybe the syntactic sugar required to implement this messed up another part of the parser? Dunno, but it can't just be that self assignment to literals is invalid b/c lots of other stuff in Ruby prevents assigning literals just fine.

[Dave]

@steveMidgley I should've included the source for that second quote from the author - blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/2710.

[Steve Midgley]

@Dave Thanks. It seems like the core issue is in #2 - the assignment affects the variable not the object inside Ruby? Since variables aren't objects (I think variables are only things that aren't objects), you can't use object methods to solve this problem. It appears this would be a good example of why Ruby is very close to "objects all the way down" but not quite.

[danielricecodes]

@JörgWMittag everything is an object in Ruby. Everything.

[Jörg W Mittag]

@danielricecodes: No. There are lots of things which aren't objects in Ruby. Variables are one of them. Variables reference objects, but they are not objects.

[danielricecodes]

@Jörg - not to take this thread in another direction but the Ruby website itself states that everything is an object. ruby-lang.org/en/about. Pm me if there's a subtle distinction I'm missing here.

[Jörg W Mittag]

@danielricecodes: Yes. It also says that Ruby is an interpreted language, and we all know that there is no such thing as an interpreted language; interpretation is a property of the implementation not the language, and in fact all currently existing Ruby implementations have at least one compiler, some even multiple compilers. Section 6.4 of the ISO Ruby Language Specification says "A block itself is not an object" and 6.2.1 says "A variable is denoted by a name, and refers to an object, which is called the value of the variable. A variable itself is not an object."

[Jörg W Mittag]

@danielricecodes: The book The Ruby Programming Language written by matz himself says "every value is an object", it does, however, not say that "every thing is a value", there are plenty of "things" that aren't values and aren't objects: syntax, for example, is not an object. There's a question here on SO asking what the class of unless is, and the answer is: none, because it's a keyword, and keywords aren't objects, thus they don't have a class.

[vol7ron]

I agree with the concern; if ++ is bad, then +=1 would be bad as they are almost the same thing. One would think that would be okay because why create an operator that will save you 1 character or something that is hardly used?, but the fact that many other scripting and non-scripting languages include the ++ operator -- including Perl, PHP, JavaScript, VisualBasic, [flavors of] C, Java -- makes it an almost universal operator, like the assignment = operator. One of the only other popular languages does not include is Python, but you miss out when you want to do array[i++]

[blio]

In fact, a integer number do not hold a reference to a object, so when x=1, when you do x++, what you do is 1++, it does not change the value of x, it does not make any sense.

[davmac]

In C, the expression var++ increments the value stored in the object denoted by var (and yes, primitive values are stored as objects in C). Your answer doesn't explain why this couldn't also be the case in Ruby (because, of course, it could - but the decision was taken by the language designer not to. The real question is why? It's not as simple as there being something unique about Ruby's object system).