[cfe-commits] r143399 - in /cfe/trunk: lib/CodeGen/CGBlocks.cpp lib/CodeGen/CGExpr.cpp test/CodeGenCXX/block-rvalue-reference-capture.cpp
dgregor at apple.com
Wed Nov 2 10:19:22 PDT 2011
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
>>>>> 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
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);
__block T &captured_x = x;
More information about the cfe-commits