The postincrement and postdecrement operators should be redefined in terms of the preincrement operator. Define x++, x-- as being identical to ++x, --x, except that it should be illegal to use the return value of x++. In effect, this means that internally, x++ will become cast(void)(x+=1); Currently, overloaded operators for opPostInc, opPostDec() always involve a potentially expensive creation of a copy of the object, which is almost never used. This useless and painful feature inherited from C++ can safely be dropped. It's likely that there is no extant D code which uses this feature.
I use it in dcollections iterators to do increment and decrement, sometimes I use the return value (which is a copy of the iterator before incrementing). However, I wouldn't mind getting rid of opPostInc *if* opInc was a true operator, instead of the hackish += 1, which makes no sense for iterators. I have to put warning comments in the opAddAssign saying you should only call it via ++i, because doing i += x can be an O(n) operation. Yes, I know I could implement these as functions instead of operators, but the syntax is so perfect for it, and it seamlessly fits with pointers.
A better solution would be to define i++ in terms of ++i and require the compiler to do the value preservation as a copy or by delaying the function call until after the value is used.
Steven - I agree, it should be opInc. The opAddAssign(1) design assumes that x+=int is valid, and that's not necessarily true. It plays havoc with templated operators, too. BCS - I'm not sure that that would work without guaranteed value copy semantics. (This is part of the reason why postinc is such a pain). Perhaps that can be done now with D2 copy constructors. The question is, do we really need this functionality anyway? Sure, C++ has it. But C++ has a lot of useless stuff.
"The postincrement and postdecrement operators should be redefined in terms of the preincrement operator." Implemented in DMD2.041. (though not in the form suggested in this bug report).
Perfect. Is it a solution indistinguishable from that described in TDPL?
(In reply to comment #5) > Perfect. Is it a solution indistinguishable from that described in TDPL? Yes. The solution in DMD and TDPL is more complete than I proposed. I proposed to just make it illegal to use the return value. The solution we have now creates a temporary copy to return. Bug 4231 remains; the solution to that would be to not create the temporary if the return value isn't required. As a side-effect, this will give us optimal performance <g>.
Great. The spurious creation of an extra value is important, so I suggest you keep this bug open or open a different one. Thanks!