www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2657] New: Remove opPostInc, opPostDec

reply d-bugmail puremagic.com writes:
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.


-- 
Feb 13 2009
next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Feb 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Feb 13 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Feb 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 01 2010
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 01 2010