Rvalue references - The resolution

[Steven Schveighoffer]

On Mon, 06 May 2013 10:40:06 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 5/6/13 10:31 AM, Steven Schveighoffer wrote:

>> By "completely innocuous" you mean valid? I don't think the above is  
>> valid.
>
> I meant valid-looking.

OK.

>> It seems to compile and work for me, but I don't know what the point is,
>> since you are being mysterious :)
>
> If x > 100, the code is saving a reference to a destroyed temporary. If  
> you couldn't see it, how many do you expect would see similar issues in  
> even simpler and cleaner D code?

No, I was wondering whether the compiler detects this and keeps the  
temporary in scope (after all, it is in control of that temporary's  
lifetime).  I called cout with that temporary as the reference, and it  
seems to not have clobbered it (outputs 100).  I have not had such "lucky"  
experience with D.  Coming from the perspective of a complete compiler  
ignoramus, I have no idea what is really happening :)  I know that it's  
common practice to throw rvalues and catch them as references, which seems  
to be handled correctly by the C++ compiler.

>
>> A long time ago I wrote a logging feature for C++ that returned an
>> rvalue (maybe it was an rvalue reference, it was a long time ago, and I
>> don't have the code anymore). That would collect log messages via the <<
>> operator, and then when the line was through, the destructor would
>> output that line to the logger. The logging object fetched would either
>> be a dummy no-output object, or a real logger, depending on the logging
>> level selected. If the logger was disabled, no message was constructed,
>> making it somewhat lazy (any expressions in the line would obviously be
>> executed, just like any standard logger). It worked without a hitch as
>> long as we used it. The rvalue stayed allocated and valid throughout the
>> whole line, even though it was passed into each << operation by  
>> reference.
>
> Not relevant.

How so?  I thought the point is you were saying that we couldn't handle  
passing a ref bound to an rvalue to another function (because D destroys  
it early?), that is precisely what I did.  I felt it was completely  
on-point.

-Steve