On 10 May 2013 05:39, Rob T <alanb@ucora.com> wrote:
On Thursday, 9 May 2013 at 19:26:37 UTC, Jonathan M Davis wrote:
On Thursday, May 09, 2013 19:45:16 Peter Alexander wrote:
It seems that 'auto ref' would be suitable, provided we can find
a way for it to work with normal functions (in a sensible way,
not like templates).

That's trivial enough. All you have to do is lower code like

auto foo(auto ref int i) {...}

foo(5);

to something like

auto foo(ref int i) {...}

auto __temp = 5;
foo(__temp);

And temporaries end up on the stack anyway, so you wouldn't really even have
to lower it to quite like that, but that's what would be happening
conceptually. It's also what would happen if plain ref accepted rvalues. It's
just that we avoid certain classes of issues by having something distinct from
plain ref for accepting rvalues by ref. The implementation itself is
straightforward. If anything, I think that argument comes down primarily to
two things:

1. Should plain ref accept rvlaues?

2. If plain ref shouldn't accept rvalues, then what attribute do we use to
accept rvalues by ref?

And given that the whole point of adding auto ref to the language was to solve
exactly this problem, I think that it makes perfect sense to just use auto
ref.

- Jonathan M Davis

So, if I understand correctly, auto ref for templates will end up doing exactly the same thing as auto ref for non-template functions? That would be perfect, otherwise it'll be terribly confusing.

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.

So to say it will do 'exactly the same thing' is a misunderstanding. I argue that 'auto ref' as applied to non-templates will only create confusion, it effectively re-enforces the type of confusion that you have just shown.

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.
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.
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.