www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new DIP39: Safe rvalue references: backwards compatible, safe against

reply Timothee Cour <thelastmammoth gmail.com> writes:
Abstract

We propose to introduce rvalue references that are:
* safe: guarantees memory safety so that references will always point
to valid memory.
* backwards compatible: current valid D code will continue to work
without change. In addition, additional code becomes valid with call
site rvalue ref annotation.
* safe against ref/nonref code evolution: call site rvalue ref
compulsory annotation turns ref/nonref changes into compile errors
instead of silently changing code behavior.
* both const ref or ref can be used with rvalue refs (more flexible than C++)
* no call site ref annotation when input ref argument is already an
lvalue (different from C#), for backwards compatibility (and making it
less verbose)
* compatible with UFCS
* compatible with DIP38: can use same inref/outref internal compiler
annotation for input references that can be returned by ref by a
function. But DIP38 is optional.

link: http://wiki.dlang.org/DIP39
May 10 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 11 May 2013 at 02:24:02 UTC, Timothee Cour wrote:
 Abstract

 We propose to introduce rvalue references that are:
 * safe: guarantees memory safety so that references will always 
 point
 to valid memory.
 * backwards compatible: current valid D code will continue to 
 work
 without change. In addition, additional code becomes valid with 
 call
 site rvalue ref annotation.
 * safe against ref/nonref code evolution: call site rvalue ref
 compulsory annotation turns ref/nonref changes into compile 
 errors
 instead of silently changing code behavior.
 * both const ref or ref can be used with rvalue refs (more 
 flexible than C++)
 * no call site ref annotation when input ref argument is 
 already an
 lvalue (different from C#), for backwards compatibility (and 
 making it
 less verbose)
 * compatible with UFCS
 * compatible with DIP38: can use same inref/outref internal 
 compiler
 annotation for input references that can be returned by ref by a
 function. But DIP38 is optional.

 link: http://wiki.dlang.org/DIP39

OK, First remark on the way the DIP is presented. You start right away with example which make it hard to understand o general big picture. Second, ^ is not unused in D and the DIP introduce an ambiguity here. Making the temporary creation explicit is an idea that hasn't been explored that much. I have to think more about it.
May 11 2013
prev sibling parent "timotheecour" <timothee.cour2 gmail.com> writes:
 OK, First remark on the way the DIP is presented. You start 
 right away with example which make it hard to understand o 
 general big picture.

I've clarified differences with the rejected DIP36 in the abstract and added more context.
 Second, ^ is not unused in D and the DIP introduce an ambiguity 
 here.

Indeed, it's used in XOR; I've clarified this point. It should still be unambiguous as XOR is binary.
 Making the temporary creation explicit is an idea that hasn't 
 been explored that much. I have to think more about it.

Could you point out to any potential pitfalls, when used as described in section 'Implementation details' ? I've also incorporated a useful suggestion from Dmitry S, which is to allow LV^ to create a temporary from an lvalue reference, as oppose to result in compile error in that case, see the updated DIP.
May 12 2013