Bug 2657 – Remove opPostInc, opPostDec

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2009-02-13T09:48:00Z
Last change time
2015-06-09T05:15:22Z
Assigned to
nobody
Creator
clugdbug

Comments

Comment #0 by clugdbug — 2009-02-13T09:48:23Z
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!