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
