[PATCH] [C++11] Support for capturing of variable length arrays in lambda expression.

[Hal Finkel]

----- Original Message -----
> From: "Richard Smith" <richard at metafoo.co.uk>
> To: "a bataev" <a.bataev at hotmail.com>, dgregor at apple.com, gribozavr at gmail.com, hfinkel at anl.gov, richard at metafoo.co.uk
> Cc: cfe-commits at cs.uiuc.edu
> Sent: Sunday, July 13, 2014 7:17:59 PM
> Subject: Re: [PATCH] [C++11] Support for capturing of variable length arrays in lambda expression.
> 
> The [C++ Array Extensions draft
> TS](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html)
> specifies how the C++ committee thinks VLAs in C++ ("Arrays of
> Runtime Bound") should work, and I think it has different semantics
> for lambda captures from those provided here =( In particular, it
> only allows the array bound expression to be evaluated a single
> time, so the array bound itself must be captured, rather than the
> variables that it references.
> 
> So, we have a choice: we can go with what you have here (which seems
> reasonable if we're providing the C-style VLAs), and we should do
> something different if instead we want to align ourselves with the
> Array Extensions draft TS and ARB semantics. If Array Extensions is
> going to become a full TS, then we'll want to align with it
> eventually, and it doesn't make sense to me to differ from it now,
> but it's not completely clear if that's going to happen (there
> seemed to be weak consensus at the previous committee meeting to
> abandon it).
> 
> Thoughts?

Regarding the committee, I think there is weak consensus to replace dynarray with some other container-compatible stack-based allocation scheme, and no particularly clear idea what that should be. There are also strong objections to having ARBs without some container-compatible scheme. To the question at hand, I think it would be really valuable to have some experience attempting to implement the proposed ARB semantics, and I'm certainly interested in hearing what the downsides are compared to the semantics we have here (and are using for OpenMP).

 -Hal

> 
> http://reviews.llvm.org/D4368
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory