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

[Jonathan M Davis]

On Friday, July 20, 2018 16:42:54 aliak via Digitalmars-d wrote:
> On Friday, 20 July 2018 at 13:21:11 UTC, Jonathan M Davis wrote:
> > On Friday, July 20, 2018 05:16:53 Mike Parker via Digitalmars-d
> >
> > wrote:
> >> [...]
> >
> > I am completely against allowing ref to accept rvalues without
> > some sort of attribute indicating that it should be allowed to
> > (e.g. @rvalue ref). Allowing ref to accept rvalues goes
> > completely against the idea that ref is for passing an object
> > so that it can be mutated and have its result affect the
> > caller. With this DIP, we'd likely start seeing folks using ref
> > all over the place even when it has nothing to do with having
> > the function mutating its arguments, and that's not only
> > error-prone, but it obfuscates what ref was originally intended
> > for.
> >
> > [...]
>
> I kinda agree with this, just not so strongly I think.
>
> But as for a UDA, maybe @implicit from the copy constructor DIP
> can be reused here?
>
> void f(@implicit ref A a) {}

I don't know. Maybe. I'd certainly prefer @rvalue, since it would be clearer
(and slightly shorter for that matter), and I don't really agree with copy
constructors requiring @implicit anyway. But at the moment, I don't see a
technical reason why the attribute couldn't be reused.

> On a side note, I'm not familiar with the talks that've gone
> around the keyword "in", and I see there's a deprecation issue on
> bugzilla [1]. Can "in" be added here? "in ref" or just repurposed
> completely?

in was originally supposed to be const scope, but it's really only ever been
const (except for with delegates), since scope hasn't ever done anything for
anything other than delegates, and it was never really defined what scope
was supposed to do exactly - just the general idea that it was supposed to
prevent escaping, not what that really meant in practice or what exactly it
didn't allow to escape. DIP 1000 actually defines what scope does in detail
and makes it work for far more than delegates. However, if in were then to
actually mean const scope as originally intended, then a large percentage of
code would break if it used -dip1000 (and would of course break once
-dip1000 becomes the default), so in has officially become just const.
However, some folks are quite unhappy about that, and -dip1000 breaks tons
of stuff anyway, so arguably, we should just allow in to mean const scope
and have it break whatever it breaks. So, what's actually going to happen
with that is unclear - especially since we really don't have a clean
migration path to making -dip1000 the default anyway, But for now, in just
means const.

Regardless, in has never had anything to do with ref. So, making it imply
ref now would definitely break code, and since in has always implied const,
if we were talking about using in for any of this, we might as well just go
with const ref like C++ does, though given how restrictive D's const is,
that's arguably a very poor solution.

- Jonathan M Davis