auto ref is on the docket

[Manu via Digitalmars-d]

On 28 June 2015 at 08:50, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>>
>> [..]
>
>
> That's what auto ref was originally introduced to do. The reason that it
> works only with templates is because Walter misunderstood what Andrei was
> proposing. So, it makes sense to use it for what it was originally intended
> for and implement it as proposed with non-templated functions. Now, that has
> the downside that we can't use it with templated functions in a fashion that
> avoids template bloat,

Stop repeating that. It's not got anything to do with code bloat, you
can't use it because template auto ref doesn't pass rvalues by ref, it
passes them by value, which means it's not a ref in any way, and it's
not what the user wants.
I can easily get the same behaviour by not-typing 'auto ref', which I
happily do in all cases that I want something to be passed by value.
But we're not talking about by-val, we're talking about ref.

It's simple; I want to pass something by value, or I want it to pass
by ref... there is no middle ground, it's an explicit binary statement
about how the parameter shall be passed. I don't care about lvalues or
rvalues. There is no case where I want the compiler to not do the
thing I told it to. And if there were a hypothetical case - where
ref-ness were dependent on some conditions, I'm confident I could
easily express that with existing mechanisms in D. I don't need a
weird compiler defined semantic to try and do something smart that
turns out never to be what I want.


> in which case, using a new attribute would make
> sense, but this _is_ what auto ref was originally for. And if we're going to
> use a new attribute, scope ref makes no sense precisely because the escaping
> issue is only part of the problem with accepting lvalues and rvalues with
> the same parameter, since you could easily have a function which is not
> supposed to escape the argument in any way, and yet it needs to be mutating
> the argument via ref for the caller, and it should not be accepting rvalues.
> So, in that case, if scope were fully ironed out, it might make sense to use
> scope ref when the intention was that the argument be mutated and not accept
> rvalues and that in not escape the function. It could also be that scope ref
> prevents returning by ref, since that's escaping the function, whereas when
> you pass an rvalue to the non-templated auto ref, you may very well want to
> return it by ref. So, if we were to use scope ref for this, we'd be mixing
> two largely orthogonal issues - escaping arguments and having a function
> accept both lvalues and rvalues - and it would cause us problems if and when
> we actually, fully defined scope.
>
> We need to either use auto ref for this as originally intended or use a new
> attribute which does so so that we can use it with both templated and
> non-templated functions. I think that it's quite clear that scope ref does
> _not_ make sense in this case, and it's already been rejected by Walter and
> Andrei anyway.

scope ref is only related to the safety of passing temporaries by
reference to functions that may retain a pointer, it has nothing to do
with lvalues or rvalues; stack locals are equally unsafe right now as
rvalues would be.

const is the thing you're looking for that says "this isn't to be
changed", such that it makes sense to pass an rvalue.

scope was proposed as a means to address the "rvalues -> ref is
unsafe, the callee might sequester a pointer somehow" argument. If
we're not interested in scope (ie, escape analysis), then we're not
interested in ref safety in general (proposed scope applies to a much
wider set of cases than just rvalues).
That's fine, I don't really care, but then you can no longer make the
argument above that safety affects this debate, at which point you
arrive at C++ where rvalues can pass to const ref, as should be the
case here. End this auto-ref nonsense, const ref is enough.