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

Reply via email to