[cfe-dev] Lambda expr AST representation

[Richard Smith]

On Thu, Oct 4, 2012 at 2:18 PM, James Dennett <james.dennett at gmail.com>wrote:

> 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.


Yeah, I agree that that would be fine. 5.1.2/3 generally restricts similar
changes to the closure type, but this case isn't observable behavior, so it
seems permissible. What goal are you working towards here? (Is this for the
benefit of a debugger?)


> 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).
>

Well, the rule I quoted only applies to capture by copy, where there really
do have to be the specified members, under 5.1.2/14 and 5.1.2/3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121004/55c2788b/attachment.html>