http://d.puremagic.com/issues/show_bug.cgi?id=2657

           Summary: Remove opPostInc, opPostDec
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: clugdbug@yahoo.com.au


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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2657





------- Comment #1 from schveiguy@yahoo.com  2009-02-13 10:37 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2657





------- Comment #2 from shro8822@vandals.uidaho.edu  2009-02-13 11:38 -------

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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2657





------- Comment #3 from clugdbug@yahoo.com.au  2009-02-16 05:36 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2657


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #4 from Don <clugdbug@yahoo.com.au> 2010-06-01 07:08:27 PDT ---
"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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2657


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #5 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-06-01 07:12:00 PDT ---
Perfect. Is it a solution indistinguishable from that described in TDPL?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2657



--- Comment #6 from Don <clugdbug@yahoo.com.au> 2010-06-01 08:49:06 PDT ---
(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>.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2657



--- Comment #7 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-06-01 08:59:29 PDT ---
Great. The spurious creation of an extra value is important, so I suggest you keep this bug open or open a different one. Thanks!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------