[cfe-dev] Lambda expr AST representation

[James Dennett]

On Thu, Oct 4, 2012 at 1:10 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Thu, Oct 4, 2012 at 11:48 AM, James Dennett <james.dennett at gmail.com>
> wrote:
>>
>> On Thu, Oct 4, 2012 at 11:23 AM, Eli Friedman <eli.friedman at gmail.com>
>> wrote:
>> > On Thu, Oct 4, 2012 at 4:05 AM, Abramo Bagnara
>> > <abramo.bagnara at bugseng.com> wrote:
>> [...]
>> >> Also, I've noted that lambda class fields generated for captured
>> >> variables are anonymous instead to have the name of the captured
>> >> variable.
>> >
>> > That's what the standard says, sorry.
>>
>> Does it?  That doesn't match my understanding, which is that the
>> standard doesn't specify the names.  Can you point at that text in the
>> standard?
>
>
> 5.1.2/14: "For each entity captured by copy, an unnamed non-static data
> member is declared in the closure type".

Thanks for the reference.

That wording makes lots of room under "as-if", as all that's required
is that valid user code can't use (or be affected by) the names used
for the closure type.  I see nothing in 5.1.2/14 that prevents an
implementation naming the captured "foo" as "__captured__foo" or
similar.  Well-defined code can't tell the difference between an
unnamed member and a member with a reserved name, AFAIK.  There don't
even have to _be_ the specified members (and hopefully implementations
will be smart enough not to make closure types which hold nothing but
references to n local variables, when they could just re-use the stack
frame).

Most of the wording around closure types is meant to mean (very)
roughly "implementations can do what they like, within limits, and
users can't look".

That said, so long as the AST is rich enough for tools to navigate
from the capture type's members back to what they captured from, I
don't think this is particularly hard to work with.  Even if Clang's
AST gave somewhat more friendly names, they still wouldn't match the
original names exactly, so that work would have to be done anyway.

-- James