auto ref and non-templated functions

[Jonathan M Davis]

On Thursday, December 27, 2012 06:26:38 deadalnix wrote:
> On Wednesday, 26 December 2012 at 22:52:29 UTC, Jonathan M Davis
> 
> wrote:
> > On Wednesday, December 26, 2012 23:02:25 deadalnix wrote:
> >> Sound like the wayt o go for me. But is ato ref needed in such
> >> case ? Why not simply allow ref to behave that way ?
> > 
> > Because there's a very large difference between a function
> > intended to take
> > arguments by ref and one where you don't care. For instance,
> > what if popFrontN
> > suddenly accepted rvalues? Using it with rvalues would do
> > nothing. We had
> > problems with std.conv.parse precisely because there was a
> > compiler bug that
> > allowed you to pass string literals to it in spite of the fact
> > that it takes
> > its argument by ref and needs to mutate its argument.
> 
> That is a const bug not a ref bug.

No, it's not. A function which takes its argument by ref is specifically 
intended to mutate its argument, otherwise it wouldn't take the argument by 
ref. Allowing such a parameter to be passed an rvalue makes it so that the 
function does not do what it's intended to do and will easily cause bugs.

C++ made it so that const& would accept rvalues with the idea that if it were 
const, then you obviously didn't want to mutate the argument, and you could 
then use it as a means to avoid unnecessary copies. But with how restrictive 
const is in D, we really should have a means of declaring a function parameter 
such that it's intended to avoid unnecessary copies but isn't necessarily 
const and is obviously not intended to mutate the original (though as long as 
the parameter isn't const, mutation is obviously still a possibility, and 
const is required to guarantee that that doesn't happen - _that_ could be a 
const-related bug). But allowing ref functions to accept rvalues is an 
incredibly bad idea, because it's mixing two very different idioms - taking an 
argument by ref in order to mutate that argument and possibly taking an 
argument by ref in order to avoid a copy. It never makes sense to take an 
rvalue by ref. rvalue arguments need to use moves, not ref.

The suggestion of creating a variable with limited scope which rvalues are 
assigned to with auto ref allows for you to only have one function overload 
and yet clearly separates it from functions which are intended to mutate their 
arguments.

> > With auto ref, you're specifically saying that you don't care
> > whether the
> > function is given an lvalue or rvalue. You just want it to
> > avoid unnecessary
> > copies. That's very different. And auto ref then not only then
> > protects you
> > from cases of passing an rvalue to a function when it needs an
> > lvalue, but it
> > makes it clear in the function signature which is expected.
> > 
> > - Jonathan M Davis
> 
> I suspect making the distinction is complicating uselessly the
> language for a benefit that isn't really clear.

Well, I strongly disagree. I think that making ref accept rvalues is just 
begging for bugs. Not even C++ allowed that. They restricted it specifically to 
const&.

- Jonathan M Davis