The liabilities of binding rvalues to ref

[Steven Schveighoffer]

On Thu, 09 May 2013 17:45:33 -0400, Peter Alexander  
<peter.alexander.au at gmail.com> wrote:

> On Thursday, 9 May 2013 at 20:59:14 UTC, Steven Schveighoffer wrote:
>> I should restate: The idea that restricting rvalues from binding to  
>> refs *except* the case where it binds to 'this' is a hack.  The binding  
>> to 'this' pre-dates the restriction.
>
> Ah ok. I do agree that the asymmetry is quite hacky, although binding to  
> 'this' isn't quite the same as binding to ref.

It's exactly the same actually.  'this' is an implicit ref argument.  I  
don't see how it's any different.

We also currently have a hack where ++ doesn't work on rvalues  
artificially, but an .increment() function does.

>>> I'm not sure about how common it is, but I really don't like the idea  
>>> of calls like swap(1, 2) being legal. Seems like a step backward from  
>>> C++.
>>
>> Why is it so bad that that is legal?  Really hard to stop people from  
>> writing incorrect code.
>
> You could apply the same argument against static typing, e.g.  
> "swap(apple, orange) looks wrong, so why is it so bad not to catch the  
> type error at compile time?"
>
> I think we can agree that while it's not possible to stop people from  
> writing incorrect code 100% of the time, there is still benefit to  
> catching as many cases as practical.

I define practical as catching as many things that shouldn't work as you  
can without making it impossible to write things that should.

-Steve