[cfe-commits] r143399 - in /cfe/trunk: lib/CodeGen/CGBlocks.cpp lib/CodeGen/CGExpr.cpp test/CodeGenCXX/block-rvalue-reference-capture.cpp

[Douglas Gregor]

On Nov 2, 2011, at 9:02 AM, Sebastian Redl wrote:

> On 02.11.2011 16:55, jahanian wrote:
>> On Nov 2, 2011, at 7:59 AM, Douglas Gregor wrote:
>> 
>>> On Nov 2, 2011, at 1:33 AM, John McCall wrote:
>>> 
>>>> On Oct 31, 2011, at 4:44 PM, Fariborz Jahanian wrote:
>>>>> Author: fjahanian
>>>>> Date: Mon Oct 31 18:44:33 2011
>>>>> New Revision: 143399
>>>>> 
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=143399&view=rev
>>>>> Log:
>>>>> Adds IRGen support for captured rvalue references in blocks.
>>>>> In this case, temporary value is copied into block descriptor
>>>>> as their own copy to work on. // rdar://9971124
>>>> Sorry for missing this earlier, but I really don't think is the right
>>>> thing to do.  Block captures of l-value references capture a
>>>> reference;  making block captures of r-value references capture
>>>> a copy is bizarrely inconsistent.
>>> 
>>> What do you propose? Capture the reference, even though it's almost surely going to refer to a temporary?
>> In the absence of any precedence of how to treat rvalue reference in code gen. A compromise may be to make the
>> copy as is currently done, but establish a reference to it on entry to the block. In essence, temporary is moved to the
>> block descriptor. But I am not sure if this will make any difference in terms of semantics of such references.
>> 
> What are the semantics of rvalue references captured by C++11 lambdas? 
> Even if there is no intuitive handling of the situation, following C++11 
> lambdas would at least have the advantage of not having two *different* 
> surprising behaviors. (Or do C++'s explicit captures make the question 
> moot?)

Explicit captures don't make the question moot. The default default would be to capture by reference; that default can be overridden with a capture-default of =, or by explicitly capturing the variable without &.

Just following what lambdas do doesn't necessarily make sense here, because blocks skew more toward safety (with implicit copying, implicit retains, and so on) than lambdas.

> Alternatively, we could just forbid the capturing of rvalue references. 
> Let the user make an explicit choice by either creating a local copy or 
> a local lvalue reference.


This might just be the best solution, since the only seems that is clear is that there are no clear semantics :)

Forcing users to perform the capture makes them choose between, e.g.,

	__block T captured_x = move(x);

or

	__block T &captured_x = x;

	- Doug