Re: [lambda] Segmentation fault in simple lambda program

[Jason Merrill <jason at redhat dot com>]

On 08/03/2009 09:36 PM, Adam Butcher wrote:
> Thanks.  I haven't any copyright assignments on file -- this is my first dabbling with gcc and I've been doing it
> mostly to experiment with C++ lambda support and non-standard extensions such as polymorphic lambda support.

OK.  We'll need an assignment in order to incorporate your changes into 
GCC.  If you want to assign all present and future changes to the 
compiler, you could use the form

http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future

> Cool.  I've been working in my own repository which I rebased earlier today from trunk (r150148).  I've attached the
> rebase including the fix for generating correct copying of lambda classes (re-laying out after parsing body).

Hmm, having the new changes folded into the old changes is kind of 
inconvenient, but I suppose I can deal.  It's moot anyway until your 
assignment is on file.

Incidentally, comments like

/*
 *
 *
 */

aren't customary in GCC sources; that's just something John did that 
we'll need to clean up before the code goes into the trunk.  There are 
other formatting irregularities, some of which I've corrected.

> It also
> fixes return type deduction which didn't work after updating to 4.5 as build_lang_decl no longer accepts DECL_RESULT
> (I replaced it with build_decl directly which seemed to work fine).  There were a few other things like placement of
> GTY (()) and replacing preservation of skip_evaluation with preservation of cp_unevaluated_operand and
> c_inhibit_evaluation_warnings (which seems to have been what's occurred in other places).

Oops, and I checked in my merge without even testing that it would 
build...guess I'd better fix it.

> Experimenting with a working version and seeing it's issues will be useful to me.  To others to maybe.  With concepts
> gone from C++0x and being reworked for C++15(?) maybe support for polymorphic lambdas could be reintroduced? -- though
> I'm sure its much too late for that and that its likely been around the buoy many times.  From what I have read I got
> the idea that the Callable concept was the primary reason for polymorphic lambdas not being accepted.

I don't know what the reasoning was there, but people have been somewhat 
conservative about what usages of lambdas are allowed for fear of 
unforseen implementation issues.  Certainly having a working 
implementation would go a lot toward convincing people to allow it, even 
if it doesn't make it into C++0x.

> Implied template typename arguments via auto are not currently supported.  The syntax parses but I haven't yet
> synthesized the template arguments and therefore not replaced the auto's with them so it doesn't compile.

Since templates work so differently from normal functions, I'm a little 
uncomfortable with the idea of templates that don't involve any template 
syntax, just the use of auto in the parameter list.  But I'm open to 
giving it a try, at least in the lambda context.  Maybe outside of 
lambda it could be used with a small template introducer...

> I'd welcome feedback on the syntax and semantics and of course any fundamental things I've missed by coming up with
> such a syntax!
>
>  From a grammar point of view I've just expanded lambda-parameter-declaration to start with:
>    lambda-template-param-decl [opt]
> where lambda-template-param-decl is:
>    <  template-parameter-list>

Makes sense.  I suppose to specify explicit template arguments users 
would have to write

lambdaob.operator()<template-arg>(fn-arg)

so we'd really expect them to be only deduced.

> # unspecified typename inferred by use of auto in function parameter list
>        [=]<typename YY>  (auto* x, YY y) { return x->Func( y, a, b ); };
> # is translated into
>        [=]<typename YY, typename X>  (X* x, YY y) { return x->Func( y, a, b ); };

A mixed declaration like that seems rather ugly to me; I'd hope that 
people would use either explicit template args or auto in a particular 
lambda, not both.  But I suppose that's not reason enough to forbid it.

Jason