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

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.

> 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.