On 08/04/2009 04:52 AM, Adam Butcher wrote:
Yes sorry about that. I appreciate the issue. I had taken a branch of trunk
and applied the lambda changes to it to
keep only lambda changes on my working branch (allowing simpler future
rebaseing). There were a number of things I
had to change to to get the lambda changes a) building and b) working with test
programs. Unfortunately I did all
this in one commit. Not very helpful. I will mail you my 'fixes' diff against
the latest lambda branch head
independent of the rebase noise if you want.
No need, it was easy enough to just apply it on another branch and
compare against my branch. Git makes so many things easier...
Hopefully. From my point of view the class generated by a lambda expression
should be equivalent to something you
could write yourself -- aside from the single stack-pointer reference
optimization which only a compiler could achieve
-- the class has a name, albeit invisible to the user (except in
errors/warnings), and instances of should be useable
just as if there were user-defined functors. I'm sure there are things I've
overlooked but hopefully this
proof-of-concept will help to allay people's fears.
I agree.
Incidentally, how does it work to just move the existing call of
finish_struct to after we parse the body? I don't see why we need it to
be complete while we're in the body.
I suppose I'll go ahead and review the current code; I haven't really
looked at it closely yet.
Jason