On Thu, Jan 24, 2019 at 12:05 PM kinke via Digitalmars-d-announce <digitalmars-d-announce@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?
