On 10 May 2013 10:31, Jonathan M Davis <jmdavisp...@gmx.com> wrote: > On Friday, May 10, 2013 10:08:37 Manu wrote: > > 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_. > > The runtime check for ref that we agreed on already solves the @safety > problem. So, I see no point in discussing the @safety problem further > unless > there's something wrong with the runtime check solution. And yes, the > @safety > problem is not just a question of rvalues. But whether ref should accept > rvalues is very important with regards to being able to write and > understand > correct and maintainable code. > > The question of accepting rvalues that we are therefore discussing has > _nothing_ to do with @safety. It's entirely a question of avoiding other > types > of bugs - like accepting nonsense like swap(5, 7), which in that case is > fortunately obvious but is not obvious in the general case. IMHO, it needs > to > be clear when a function intends to take an argument by ref because it > intends > to mutate the argument and when it intends to take an argument by ref > because > it wants the efficiency boost of avoiding the copy. In the first case, it > makes > no sense to accept rvalues, and in the second case, you definitely want to > accept rvalues. As such, having different syntax is needed (be it auto ref > or > @acceptrvalue or whatever). > > I'm not entirely against adding a new attribute for that (it would have the > added benefit of not needing a compiler optimization to guarantee that a > templated function takes its argument by ref when passed an rvalue), but > Walter and Andrei don't want to add new attributes if they can avoid it, > so I > don't expect them to be okay with adding a new attribute. And since auto > ref > was originally supposed to be this attribute, I'd _much_ rather have that > do > it than make the mistake of letting ref accept rvalues. >
What were the arguments again against ref const()? You're talking about making it clear that the function isn't planning on mutating the given rvalue... I understand that const is stronger than C++, but is it actually a deal-breaker? It's the most logical fit here.