Re: [boost] [range] adaptors vs. rvalue to lvalue& binding

Subject: Re: [boost] [range] adaptors vs. rvalue to lvalue& binding
From: Bronek Kozicki (brok_at_[hidden])
Date: 2012-03-22 12:20:56

Actually I can see now that my last message contains few errors.

On 22/03/2012 15:44, Bronek Kozicki wrote:
>> So do we want to change boost::sort( Rng& ) to boost::sort( Rng&& )
>> ? That would make boost::sort( std::vector() ) ok.
>
> I fail to see what's wrong with this. Pointless - yes, but inducing
> runtime errors - no. Although of course I could have missed something.
>
> Back to your function - perhaps taking unqualified template parameter
> is not the best idea, and if you want to take a range you might want to

... or perhaps not. Taking unqualified template parameter will allow you 
to write single function on anything with range-like interface, 
including boost::iterator_range itself. So, is there anything wrong with:

   template <typename Range>
   modifies_range(Range && rng);

?

>> C++ decided at
>> some point to disallow binding rvalues to lvalue&. I think the reason
>> is that rvalues are inaccessible for the caller, so modifying them is
>> likely a bug.

on second reading I can see that you asked about exactly the opposite 
binding, taking the history back to last century :) Hope someone will 
find the explanation below helpful, but the context in which I have put 
it is obviously wrong - since it only applies to C++11 :)

> no, the reason was different. The function which takes rvalue-reference
> does it in order to apply optimization (move semantics) which is
> often/easily implemented as "stealing" data from its actual parameter.
> If binding lvalues to rvalue-reference parameters was allowed, such
> "stealing" could happen implicitly, on an lvalue parameter, and would
> likely result in runtime errors. As things stand now, you have to be
> explicit about moving data away from lvalues, e.g. by using std::move()

B.