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?)
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. Sebastian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
