http://d.puremagic.com/issues/show_bug.cgi?id=3378
--- Comment #6 from Andrei Alexandrescu <[email protected]> 2010-03-04 04:17:15 PST --- (In reply to comment #5) > C99 says this about ++x: > > -------6.5.3.1------------- > The operand of the prefix increment or decrement operator shall have qualified > or unqualified real or pointer type and shall be a modifiable lvalue. > > Semantics > > The value of the operand of the prefix ++ operator is incremented. The result > is the new value of the operand after incrementation. The expression ++E is > equivalent to (E+=1). See the discussions of additive operators and compound > assignment for information on constraints, types, side effects, and > conversions > and the effects of operations on pointers. The prefix -- operator is analogous > to the prefix ++ operator, except that the value of the operand is > decremented. > --------6.5.16------------------- > An assignment expression has the value of the left operand after the > assignment, but is not an lvalue. > --------------------------------- > > It is equivalent to x+=1, and therefore not an lvalue. > > The C++98 spec also says that ++x is equivalent to x+=1, but says that the > result of x+=1 is an lvalue. (Still scantily connected.) Wait, I'm confused. C and C++ do not define ++x as x+=1, right? We shouldn't either, for reasons that we've discussed at length before (i.e. there are UDTs for which increment makes sense but addition does not.) So: (a) x+=1 is not a part of the discussion about ++x. (b) Keeping ++x an rvalue is a gratuitous incompatibility with C and C++ (c) Keeping ++x an rvalue requires extensive rework of TDPL (the bump example is taken from there) There isn't much reason to debate. It's a trivial change that has only benefits (albeit minor), I suggest we simply make it and move on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
