On 10 May 2013 08:09, Jonathan M Davis <jmdavisProg@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.