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






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







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






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



"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



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






 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




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