DIP39

DIP 39: Safe rvalue references: compatible with DIP38, backwards compatible, safe against ref/nonref code evolution.

Title:	Safe rvalue references: compatible with DIP38, backwards compatible, safe against ref/nonref code evolution.
DIP:	39
Version:	1
Status:	Draft
Created:	2013-05-10
Last Modified:	2013-05-10
Author:	Timothee Cour
Links:

Abstract

We propose to introduce rvalue references that are:

• safe: guarantees memory safety so that references will always point to valid memory.
• compatible with DIP38: can use same inref/outref internal compiler annotation for input references that can be returned by ref by a function.
• 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

Details

Suppose we have a function that takes an input by ref:

T2 fun(ref T a);

We can use it as before with an lvalue LV (backwards compatible):

fun(LV);

We can use it with an rvalue RV and a call site annotation indicating to convert the rvalue to an lvalue via a temporary: I propose the yet unused symbol '^' to denote this (unused in D), although there are alternatives, see section: 'alternative symbols for call site rvalue annotation'.

fun(RV^);

Alternative symbols for call site rvalue annotation

2 things to decide on : prefix or postfix annotation, and which annotation to use:

prefix vs postfix:

• postfix fun(RV^): (proposed): compatible with left-to-right pipelines in D: [1,2].sort.map!fun.uniq
• prefix fun(^RV): compatible with '&' location wrt RV argument

This can affect ease of disambiguation wrt existing symbols.

which annotation to use (regardless of prefix/postfix):

• fun(RV^);//unused in D, reminds of a C++ special reference extension
• fun(ref RV);//reminds of C# call site annotation, and reminds of function signature
• fun(RV@);//@ has UDA meaning in D, but that could be made unambiguous
• fun(RV#); //# has a special line reordering meaning in D, but that could be made unambiguous
• fun(RV?); //? has a special (a?b:c) meaning in D, but that could be made unambiguous
• fun(RV&); //probably a bad idea, since for a templated function fun(T)(ref Ta ) this could call fun!(typeof(RV*))(RV&)

Copyright

This document has been placed in the Public Domain.