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

[John McCall]

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?

Yes.  References are references.

Among the things that are wrong with doing a copy:
(1) It's inconsistent with the capture of l-value references.
(2) In my experience, l-value references are about equally likely
  to point into something stored on or owned by the stack, so it's
  not like those are really any safer.
(3) C++ programmers using blocks are certain to deal with both
  reference types and therefore to be surprised by the inconsistency.
(4) It has to be a copy, not a move, even though it's an r-value
  reference and the programmer presumably actually cares.
(5) Capturing a reference to a temporary or local is not actually
  dangerous except in situations where the block is copied to the
  heap, but there are plenty of APIs that don't need to do this.
(6) Unlike lambdas, there's no way to override this behavior, so
  this is actually a pretty strong expressivity constraint, and the
  workarounds either involve extra moves or terrible things like
  capturing a pointer to the temporary.

John.