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

Manu turkeyman at gmail.com
Thu Jan 24 22:38:01 UTC 2019

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?

More information about the Digitalmars-d-announce mailing list