Trouble with anon delegates.

[BCS]

Reply to Pragma,

[...]
> Thanks for the clarification.  I wanted to be sure that I wasn't out
> of my mind.
> 
> This is really disappointing.  I was working on a runtime Spirit
> engine (as a counterpart to your own library) that would use inline
> delegates as valid parse expressions:

Cool!

> 
> auto rule = ws >> '(' >> +Argument >> ')' >> { writefln("args
> parsed"); };
> 
> It works fine for this kind of stuff, but once you graduate beyond
> there and want to bind terminals to class members, you need the
> ability to perform filtering and aritmetic on them.  But once you do
> that, you find that your stack frame is all out of whack. :(

I tend to use structs for that kind of thing. They entail less overhead than 
classes.

[...]
> It would be nice if things so succinct would work as I expected.
> Instead I have to break all the delegates out into proper class
> methods, which bloats the code and runs contrary to the whole point of
> having a parser framework like this.

I've said it befor, What is needed is to allow delegate leterals to expicetly 
state there context.

auto c = new C;
return c.(char[] foo){retrun this.toString() ~ foo;}

Another thing would be non static init for anon structs. This and a few others 
would make for some neat code.

int delegate(int,int,int) Bar(int i, int j, int k)
{
   return new struct {
      int a = i;
      int b = j;
      int c = k;
      }.(int m, int n, int o){ return a*m + b*n + c*o;};
}

> 
> The ability to declare *first class* delegates as anonymous and inline
> like the above is just too tempting to leave alone.  I suppose the
> only way to have your cake and eat it too is to preserve the stack
> somehow.

I guess that is more or less what the above does.

(Where's the 2.0 wish list?  <g> )