And again, that's beside the point, which is to allow the expected "++"
semantics for immutable Numerics while also allowing in-place incrementation
for other classes which may store a mutable value, such as counters (whose
backing store may be a database, memcache, etc)

That would provide a truly Ruby-like ++ experience, aside from the fact you
can't redefine #++ for a Numeric, which probably isn't a good idea anyway.

The point is, yes indeed, numerics can be mutable.  I could if I were
so inclined write a String backed subclass of Numeric which represtend
integers as Roman Numerals and was mutable, (or Fixnum backed if we're
 feeling boring).

a+=<expression> expands to a=a+<expression>.  It's a simple syntaxtic
sugar. a++ expands to... what? Nothing.  There is no way you could
expand puts foo(a++,b) and get the desired behavior.

This discussion has gone on and on, and it's really quite pointless.
There is no good reason to include ++ in Ruby, and every reason not to.
No one can even agree on what they would expect a ++ operator to do when
used "The Ruby Way", with C programmers expecting it to work like C, and
the Rubyists expecting it to follow the Ruby way, with every operator
being a method call on that object (NOT variable).

Cheers
Florian

Am 08.11.2009 um 21:26 schrieb Tony Arcieri:

I was just trying to make clear the limitation wasn't a technical one, and
further show how a ++ operator could be "Ruby-like" while still retaining
C/C++/Java-like semantics.

On Sun, Nov 8, 2009 at 3:49 PM, Marnen Laibow-Koser <mar...@marnen.org>wrote:

http://xkcd.com/386/

..that is all.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org

On Sun, Nov 8, 2009 at 5:02 PM, Marnen Laibow-Koser <mar...@marnen.org>wrote:

http://bit.ly/w8WZA

Matter of interpretation?

BTW in all your posts on the topic, you don't seem to address pre-
increment vs post-incrememt.  (Forgive me if I'm wrong.)  If Ruby
implemented ++ and didn't address that, it wouldn't be C or C++
semantics at all.

Does

   foo {x++}

yield the incremented x to foo, or the original x? What if foo yields
several times? Increment once, or once per iteration?

What about

   x = 0
   y = case; when true; x++; end

Is y 0 or 1?

It's kind of an ink-blot test for what you think "expression" means, but
of course everything is an expression in ruby.

It's not an answer to say

   'x++' should have the same effect as 'x+=1'

because that's not even true in C.

class Foo
  attr_accessor :bar

  ...
end

This meant Foo#bar= was defined already.  I forgot I did that, and thus my
results were, well, unexpected...

[...]

Again, if you can think of an actual context where this would be useful
in Ruby, please provide actual code.

But I think the more difficult issue is the semantics.

Hmm.

Let us imagine that we were to make ++ a rebinding operator, like +=.  Not
just for Numerics, but always -- otherwise we lose the expected semantics.
Hmm.  This leads to an interesting point:

Since you can't modify the underlying object when it's immutable, it violates
POLS for ++ to ever modify the underlying object.  It would ALWAYS be a
rebinding to a new value.

The semantics of "++x" would indeed be exactly equivalent to "x += 1".  The
semantics of "x++" would be equivalent to
        magic_temporary_value = x
        x += 1
        magic_temporary_value

The question is...

Would this be useful enough to justify the hassle?  I'm not sold on it.
The postincrement form is really primarily useful for idioms that don't
make any sense in Ruby.  The preincrement form is actually sorta nice,
because it really is easier for me to read (I don't have to actually
think about whether the amount incremented by is really 1 or not).  I'm
not sure it's nice enough to justify the effort.

Also, in more productive terms:
"a += 1".size => 6
"a+=1".size => 4
"a++".size => 3
RubyForum::Thread.self.count_keystrokes => zomg !

On the other hand, it's also plain impossible to implement, for various
reasons listed numerous times prior to this humble message.

In C, "x++" yields the current value of x, and at some point between the
prior sequence point and the next sequence point, x gets incremented.
The reason that "i + i++" is *undefined behavior*, not just an unspecified
value, is that Deep Magic may occur to implement or support the
increment operators.  There's no particular guarantee -- none at all --
that such code even runs, let alone does anything specific.

That's fine.  C has "sequence points", and because expressions in C are
pretty simple and limited, you always have plenty.  Consider:

        for (i = 0; i < 10; ++i) {
                printf("%d\n", i);
        }

The evaluation of each of the control expressions in the for loop is
separated from everything else by sequence points.  There's a sequence point
between the evaluation of i for the printf and the actual execution of
printf, and another when printf is done, and so on.

Let's look at a while loop to simplify a bit:
        i = 0;
        while (i++ < 10) {
                printf("%d\n", i);
        }
In C, that should consistently yield the numbers 1 through 10.  (When i
is 0, i++ is < 10, but increments i, so printf sees 1.  When i is 9, i++
is 9, thus still < 10, but increments i, so printf sees 10.)

In Ruby, if you did something similar to this, you might write:
        i = 0
        while i++ < 10
                puts i
        end

When, exactly, do we expect that the increment happens?  This whole thing
is an expression.  I'm not aware of anything particularly equivalent to
sequence points.  Do we ensure that i is incremented before puts is called?
Consider that this whole block (while ... end) could be a single argument
to a function, because it's just an expression.

In short, the fact that control statements in Ruby are also expressions
makes it harder to run with the simple "by the end of the expression"
heuristic most people use.

Think about:

        puts i++ || i

In C, you'd have a nice solid guarantee that the increment happens before
the || (because &&/|| are sequence points).  Would you in Ruby?  I have no
clue.

I'd rather see "++count".  It's easier for me to read.