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. 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. > 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. scope says _nothing_ about that. It's all about what escapes the scope, not about how stuff gets passed. 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. 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. 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. 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. The only reason that it's not what we have now is because Walter misunderstood it when he implemented it. > 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. 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. And it's even questionable that scope as originally intended can be properly implemented anyway. > 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. - Jonathan M Davis