The liabilities of binding rvalues to ref

[Manu]

On 10 May 2013 08:09, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Friday, May 10, 2013 07:35:36 Manu wrote:
> > I don't think this is entirely true, auto ref is a template concept, that
> > is, "automatic ref-ness", it selects the ref-ness of the argument
> > automatically, at compile time, just like auto applied everywhere else
> > (selects a type for instance, at compile time). This concept doesn't make
> > any sense applied to a non-template. It *IS* a ref as specified by the
> > programmer, there's nothing 'automatic' about it.
>
> I don't buy this at all. The entire point of auto ref on parameters was to
> say
> that you wanted to accept both rvalues and lvalues efficiently. The fact
> that
> the template implementation happened to forward refness as a result was a
> happy accident.


Or perhaps it's actually the core promise that was just poorly understood
at the time?

auto ref is already described in TDPL, and it has nothing to
> do with templates there. Using auto ref on non-templated functions would be
> completely in line with what TDPL describes and would implement another
> feature from TDPL that we're currently missing.
>

Making it blindly suit the book, whether that idea was initially right or
wrong without having actually tried it out or argued it through is not a
compelling argument for my money.


> This is the reasoning for the argument behind scope ref, which to my mind
> > actually makes good sound sense, and should lead people to a proper
> > understanding of what you are actually doing.
>
> The whole point of making auto ref work with non-templated functions is to
> be
> able to say that you want to pass both rvalues and lvalues by ref so that
> they
> get passed efficiently.


Efficiency can not be implied by ref-ness. There are lots of factors, and
the programmer needs control over which is chosen.
auto ref would seem to me as something of a hack that is required when
dealing with ref and templates, because ref is not part of the type like
C++.
auto ref on templates wouldn't exist if ref was part of the type, it would
infer ref-ness automatically like C++ does. Even Walter agreed that it felt
like a hack for this reason during conversations.

scope says _nothing_ about that. It's all about what
> escapes the scope, not about how stuff gets passed.


It says it in a more pure way. The point is that it is made explicit that
the argument will not escape the scope it is given, thus, in conjunction
with ref, it becomes naturally safe to pass r-values.

So, using scope ref to
> solve that problem makes no sense, and the changes that we've proposed to
> make
> to ref to make it @safe pretty much make scope unnecessary.


I agree, that's why I'm also happy with 'ref' alone, but I still feel it
doesn't communicate as much information, which is a trivial by contrast.

scope ref would be
> virtually identical to ref given that ref already has to guarantee that the
> variable being referenced doesn't get destroyed before the ref is.


No, there are other bonuses:
 - It mechanically enforces a given argument will not have a pointer taken
and escape.
 - It gives the extra information to the programmer who can better reason
about API intent.
 - It allows 'ref' alone to retain an important function where it may
escape a pointer if it wants to.


> The only
> real difference would be that scope would presumably additionally prevent
> doing
> @system stuff like taking the address of the ref. I don't see how this
> buys us
> anything.
>

Yes this is an advantage, I listed it above. It buys the programmer some
additional flexibility/choice.

I agree that auto ref isn't a great name, but it's what we already have, and
> using it on non-templated functions would be using it for exactly what it
> was
> designed for in the first place and how it's described in TDPL.


I'm not going to change my position that it makes no sense, and is
misleading/confusing without some real arguments, which nobody seems able
to provide.
auto ref has already shown to create misunderstanding in the minds of
non-super-technical programmers. Syntax should encourage correct
understanding.

The only reason
> that it's not what we have now is because Walter misunderstood it when he
> implemented it.
>

If that's true, I'm glad he did. Or perhaps he never agreed to it in the
first place.
His misunderstanding suggests that he never actually agreed to the initial
proposal that you refer to.

> Considering the key argument against 'scope ref' is that people don't want
> > to require more attributes to make use of it, I don't see how 'auto ref'
> > satisfies this argument either.
>
> Because we already have auto ref. It just hasn't been implemented on non-
> templated functions yet even though it was supposed to be.


...so, we don't have it?

And you were
> proposing not only using scope ref with a particular meaning on function
> parameters but also adding it as a return type, which it definitely isn't
> know
> regardless of what scope of function parameters does or doesn't do.


I'm (note: not originally my proposal, although I shared the thought)
proposing that scope has a uniform meaning as applied to any variable
anywhere, where it's a local, or an argument (just a local declared in a
different spot), or a return value (yet another local, declared in a
different spot), the meaning is consistent.

And it's
> even questionable that scope as originally intended can be properly
> implemented anyway.
>

...so, the problem is no different than 'auto ref' as you mention above.
It's not implemented as drafted, and we're debating what's actually
correct. Clearly the draft was incomplete in both cases.
I only support the proposal (from others) that scope ref makes so much more
sense, and I think we've also proven it can be made to work syntactically
without holes, which I don't believe is so for auto ref.

> Thus, I am quite happy happy with 'ref', it can be made safe, satisfies
> the
> > argument above, and this seems like a very good start that we might
> > actually all agree on.
>
> As has already been discussed in this thread, it will introduce maintenance
> problems if ref accepts rvalues.
>

I'm not bothered by that personally, but if it's critically important, then
we start arguing scope ref again. Otherwise I am happy to accept 'ref' with
new added safety.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130510/0385f4ec/attachment-0001.html>