DIP 1016--ref T accepts r-values--Formal Assessment

[kinke]

On Thursday, 24 January 2019 at 22:38:01 UTC, Manu wrote:
> Shared in/out functions are very rare by contrast to out 
> parameters.

The code I write is the exact opposite of your perception - some 
occasional side-effect-mutations of params, and almost no stuff 
'returned' as out params.

> What are some legit cases where, assuming a world where we want 
> to avoid naked ref in cases where we want to receive compile 
> errors when users pass rvalues, aren't satisfied by other 
> options?

Proposed `out` semantics:
---
void increment(out long value) { ++value; }
increment(out value);
---

vs. pointer version with current `out` semantics:
---
void increment(long* pValue) { ++(*pValue); }
increment(&value);
---

The pointer workaround is both ugly (C) and unsafe (you can pass 
null).