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
