Re: [lambda] Segmentation fault in simple lambda program

[John Freeman <jfreeman08 at gmail dot com>]

I haven't been following GCC, so I need to thank Jason for forwarding 
this issue to me.

I just read through the messages on the list, and had some more comments:

> +    /* relayout again -- to allow for implicit
> +     * parameters to have been added to the capture if it was a
> +     * 'default capture' -- note that this would not be necessary if
> +     * the stack-pointer variant was implemented -- since the layout
> +     * would be known.
> +     * Relayingout here might have nasty effect if one were to query
> +     * sizeof *this from within the body -- would that even be
> +     * possible -- *this would refer to the lambda or the enclosing
> +     * class instance -- if there was one.???
> +     *
> +     * NOTE: I think this is a redefinition error; I'm just faking that
> +     * it isn't by clearing the size node... need to use stack pointer
> +     * method.  But that will likely bring its own issues -- not with
> +     * class layout though.
> +     */
> +    TYPE_SIZE (type) = NULL_TREE;
> +    finish_struct_1 (type);

Relaying out the class after the lambda body was parsed is something I 
had attempted to do, but possibly failed at.  It will absolutely need to 
be done.

> The way 'default reference capture' is implemented on the lambda branch seems to be kind of reactive.  I would expect
> that inheriting the stack somehow (maybe using just a stack pointer) would be better but without more investigation I
> don't know if that is possible or how one would go about doing it. 

This won't be suitable in the general case, because of the copy default 
capture [=].  Implicit captures will have to be reactive.

> /*
>  * Rather than looping through the identifiers used in the scope of
>  * the lambda and synthesizing individual captures of them, it would
>  * be better to ref the stack frame as transparently as possible...
>  * e.g. given just three ints i, j and k in scope:
>  * Instead of transforming:
>  *
>  *    [&] { i = 1; j = 2; k = 3; };
>  *
>  * into
>  *
>  *    [&i,&j,&k] { i = 1; j = 2; k = 3; };
>  *
>  * and thus storing three pointers to int, transform it into:
>  *
>  *    [sp=enclosing-stack-pointer] { var-from-stack(i,sp) = 1;
>  *                                   var-from-stack(j,sp) = 2;
>  *                                   var-from-stack(k,sp) = 3; };
>  *
>  * and only store one pointer.

This is preferred for reference default captures, but I was not familiar 
with stack pointer mechanics in GCC.  I just wanted to get something 
working first that could be improved later.

>  * I don't know if its possible but it may be possible to 'append'
>  * the lambda's stack to the existing scope rather than creating a
>  * new constrained scope -- from a logical point of view.

Again, this is not suitable to the general case because a lambda can 
outlast its enclosing scope.

> My motivation for investigating is that I consider constraining lambdas to be monomorphic significantly reduces their
> usefulness.   I'm sure there are many good reasons why the committee decided that it was the way to go.

I don't think it handicaps lambdas as much as some may believe, but 
still wanted polymorphic lambdas as well. There were just too many 
issues with deduction.  When I last left the discussion, the biggest 
issue in my opinion was concept map dropping.  The workaround made the 
deduction algorithm intimidatingly complex.

> The following program generates the expected code and runs correctly.
>  auto f = [&] <typename T, typename U> (T n, T const& m, U u) { i = ++n; j = u(++n); k = ++n; };
>   

This is exciting.  The main thing I failed to add was dependent type 
support, so I want to check this out.  (I need to register a new ssh key)

- John