On 10 May 2013 09:01, Rob T <al...@ucora.com> wrote: > On Thursday, 9 May 2013 at 21:55:51 UTC, Manu wrote: > >> Umm, what if the non-template counterpart returns ref? Then it doesn't >> behave the same. >> > > Yes, the non-template version cannot ref return an auto ref param, but I > would expect that neither can the template version unless auto ref is > specified as the return value. The key difference that I think can be > understood is that auto ref on the return value for a template is not the > same thing as auto ref on the param. > > For templates, you can enforce exactly the same behavior as the > non-template version by specifying a return of either ref or not, ie you do > not specify auto ref or you specify a return by value. > > If you so happen to specify a ref return of an auto ref param, I would > expect the compiler to refuse to compile no matter if it is a template > function or not. Of course you can confuse the programmer and allow such a > thing to compile only for the cases where it can return ref on the auto > ref, but IMO that'll be a big mistake as it will confuse the s*** out of > most people, and besides allowing something like that has no value at all. > > D is a complex language, so stuff like this does take some getting used >> to, >> >>> but it is very powerful and flexible, no two ways around it. >>> >>> >> If this takes 'getting used to', you're basically admitting that it >> doesn't >> make intuitive sense. >> > > Well, I suppose I cannot disagree with you on that point, so yes it is > confusing, but for sake of a solution, it is not nearly as confusing so > long as auto ref on the parameters will behave the same for both template > and non-template versions in a consistent way. I know auto ref on the > return is potentially confusing, but it does increase template flexibility > as the benefit. >
It IS confusing that auto-ref would do 2 completely different things. One automatically selecting ref-ness, the other saying "i can safely receive a temporary". There is nothing 'automatic' about the latter. Alternatively, I think Jonathan's argument against scope ref makes perfect > sense. Unless I misread something or he's dead wrong, how can scope be used > without creating even more confusion? Even if scope has some properties in > common with auto ref, it specifies something entirely different than > accepting rvalues and lvalues. This point reminds me of why we should not > be using bool as an integral type, it's the same reasoning. Which argument? Correct, it specifies something _entirely different_, it says "I can safely receive a temporary, because I promise not to escape it". This is the actual problem that we're trying to solve, and it addresses the problem head on. As I've had to re-iterate countless times, and such is the massive fallacy behind all of these threads, this whole debate is NOT about lvalues/rvalues, and I wish people would stop using the term 'rvalue' in their posts, I worry that they misunderstand the problem every time it's said. This code is broken: void f(ref int x) {} int x; f(x); x is an lvalue. This is the real problem case, and addressing this will solve the rvalue case at the same time. Passing an rvalue to a function just generates an implicit temp which is functionally identical to the above, except the lifetime of a temp is usually the life of the statement rather than the outer scope. The problem we need to solve is that of a function being able to safely receive a _temporary_.