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

Manu turkeyman at gmail.com
Thu Jan 24 23:57:08 UTC 2019


On Thu, Jan 24, 2019 at 3:50 PM Rubn via Digitalmars-d-announce
<digitalmars-d-announce at puremagic.com> wrote:
>
> On Thursday, 24 January 2019 at 23:18:11 UTC, kinke wrote:
> > 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).
>
> @safe void safestFunction() {
>      int* ptr;
>      increment(out *ptr); // can also pass null to ref/out even in
> @safe
> }
>
> It's probably going to be a hard sell to change the behavior of
> out now as well. It'd break quite a bit of code I think, did a
> search through druntime and phobos and quite a few functions use
> it. Maybe user code uses it less, I know I never use it.

I think any issues with `out` are tangential though. `out` does 'work'
right now, and it's a valid way to address the concern with respect to
one broad use case for ref.
Theoretically, `out` is the right solution for that particular class
of calling contexts, and any further issued with `out` should be taken
as a separate issue/discussion.


More information about the Digitalmars-d-announce mailing list