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

[Manu]

On Thu, Jan 24, 2019 at 12:05 PM kinke via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
>
> On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
> > We discussed and concluded that one mechanism to mitigate this
> > issue
> > was already readily available, and it's just that 'out' gains a
> > much
> > greater sense of identity (which is actually a positive
> > side-effect if
> > you ask me!).
> > You have a stronger motivation to use 'out' appropriately,
> > because it
> > can issue compile errors if you accidentally supply an rvalue.
>
> `out` with current semantics cannot be used as drop-in
> replacement for shared in-/output ref params, as `out` params are
> default-initialized on entry.

Shared in/out functions are very rare by contrast to out parameters.

> Ignoring backwards compatibility
> for a second, I think getting rid of that would actually be
> beneficial (most args are probably already default-initialized by
> the callee in the line above the call...) - and I'd prefer an
> explicitly required `out` at the call site (C# style), to make
> the side effect clearly visible.
>
> I'd have otherwise proposed a `@noRVal` param UDA, but redefining
> `out` is too tempting indeed. ;)

Maybe... but there are satisfying options for basically any case we
could imagine; and worst case, use a pointer rather than ref.
Adding stuff like @norval feels heavy-handed, and I personally judge
this issue as being severe enough to warrant that baggage.

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?