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.
Comment #1 by schveiguy — 2009-02-13T10:37:37Z
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.
Comment #2 by shro8822 — 2009-02-13T11:38:15Z
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.
Comment #3 by clugdbug — 2009-02-16T05:36:35Z
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.
Comment #4 by clugdbug — 2010-06-01T07:08:27Z
"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).
Comment #5 by andrei — 2010-06-01T07:12:00Z
Perfect. Is it a solution indistinguishable from that described in TDPL?
Comment #6 by clugdbug — 2010-06-01T08:49:06Z
(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>.
Comment #7 by andrei — 2010-06-01T08:59:29Z
Great. The spurious creation of an extra value is important, so I suggest you keep this bug open or open a different one. Thanks!