DIP 1016--ref T accepts r-values--Community Review Round 1

Manu turkeyman at gmail.com
Sat Jul 21 02:13:00 UTC 2018


On Fri, 20 Jul 2018 at 18:17, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Friday, July 20, 2018 18:04:26 Manu via Digitalmars-d wrote:
> > On Fri, 20 Jul 2018 at 18:02, Manu <turkeyman at gmail.com> wrote:
> > > [...]
> > >
> > > I think you're describing now a bug where a function returns an
> > > lvalue, but it was meant to return an rvalue.
> >
> > Sorry, wrong way around! I meant to say:
> > I think you're describing now a bug where a function returns an
> > rvalue, but it was meant to return an lvalue (ie, a ref).
>
> The function returning an rvalue isn't necessarily a bug. It's the fact that
> it was then used in conjunction with a function that accepts its argument by
> ref in order to mutate it.

It sounded like you were specifically describing something like a
property that was used to access an output range that was a member of
some other object.
Returning by-val was the 'bug' that made a copy of the output range
instead of returning a reference to it as was intended.

Was that not the scenario you were presenting?

> If a function accepts its argument by ref in
> order to mutate it, then it's a bug for it to be given an rvalue regardless
> of whether the rvalue comes from.

I don't think that's true though. It's just as much a 'bug' to ignore
such output as it is to ignore the return value of a function. (I
shamelessly ignore return values all the time!)
If the function output is not used, then it's not used.

In most cases of course, the result is used, and the programmer would
notice that they have no variable to refer to when they attempt to
refer to the result on the very next line.

> It's just that some cases are more
> obviously wrong than others (e.g. passing foo + bad might be obviously
> wrong, whereas passing foo.bar may be wrong but look correct).

Right, and I think in this example, foo.bar is to be interpreted such
that bar is a property, and it might accidentally return by-val
instead of by-ref?
In that case, 'bar' is the bug. What could it possibly mean for a
property to return an output range by-value?

It's not ref's charter to catch such a bug, and it's much more likely
to manifest in any number of other scenarios rather than an
interaction with ref.
I can't see how this is a compelling reason to dismiss all the
advantages of this DIP in favour of keeping the current semantic.


More information about the Digitalmars-d mailing list