Destructors, const structs, and opEquals

[Steven Schveighoffer]

On Mon, 06 Dec 2010 08:34:20 -0500, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Sun, 05 Dec 2010 09:18:13 -0500, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 12/5/10 12:04 AM, Steven Schveighoffer wrote:
>>> I'm totally confused. I thought the point of auto ref was to pass by
>>> value if it's an rvalue (since the data is already on the stack). If
>>> this is not the case, then why not just make ref work that way? Why
>>> wouldn't I mark all my functions as auto ref to avoid being pestered by
>>> the compiler?
>>
>> Because you sometimes do care about dealing with a true lvalue.  
>> Consider:
>>
>> void bump(ref int x) {
>>    ++x;
>> }
>>
>> Then:
>>
>> unsigned int y;
>> bump(y); // you don't want this to go through
>> short z;
>> bump(z); // you don't want this to go through
>> int w;
>> bump(w * 2); // you don't want this to go through
>
> Right.
>
> OK, so now I understand what you are saying, but now I don't understand  
> why const ref is such a mistake.  Before you explained it was because  
> when you pass an rvalue by ref, it's much more expensive, so auto ref  
> passes by ref if it's an lvalue and by value if it's an rvalue.  At  
> least that's what I understood.
>
> With const ref, you get the same behavior, plus you are guaranteed that  
> the code isn't going to do something stupid (like modify a value that  
> will be thrown away at the end).

Not sure if this got lost in the noise, I'm still puzzled about this...

-Steve