Re: [lambda] Latest experimental polymorphic lambda patches

["Adam Butcher" <adam at jessamine dot co dot uk>]

Thanks for the feedback.

Jason Merrill wrote:
>Adam Butcher wrote:
>> The following examples produce
>> equivalent functions:
>>
>>    1.   [] (auto x, auto& y, auto const& z) { return x + y + z; }
>>    2.   [] <typename X, typename Y, typename Z> (X x, Y& y, Z const& z) { return x + y + z; }
>>    3.   [] <typename Y> (auto x, Y& y, auto const& z) { return x + y + z; }
>
> IMO #3 should not be equivalent to the others; the auto template parms
> should come after Y.  And I believe that's currently the case with your
> patch.
>
Sorry, I wasn't clear.  I meant that they generate the same function from the user's point of view, not that their
internals are the same.  I didn't mean to suggest that the order of their template parameters would be the same.  It
was meant to demonstrate that using 'auto' and specifying an explicit unique typename are equivalent from a client
point-of-view.  You are correct that in #3's case the generated lambda is equivalent to:

   [] <typename Y, typename __AutoT1, typename __AutoT2> (__AutoT1 x, Y& y, __AutoT2 const& z) { return x + y + z; }

Which is, from the user's perspective, equivalent to the lambda functions defined by #1 and #2, just that the order of
the template arguments are different.

I accept that this does give a different function signature in terms of template parameter indexes.  I've assumed that
explicit specialization of the call operator is not useful and therefore the user would never see the final template
parameter list and would not need to understand its ordering.

> If you save up all the auto parms until the end and then assign indices
> and adjust the parm vector then, that will avoid reallocating the vector
> each time.
>
Yes that would be better.

> But don't worry about tidying tree_node_counts; it just tracks how many
> of a particular tree code we create, not how many we currently have.
> Normal GC throws away lots of stuff without adjusting the counts.
>
Ah okay.  Would it be worth enhancing the tree-vec interface to include block reallocation with size doubling and end
marking to allow for more efficient reallocation?  Such a structural change maybe hidden by the macro front-end.  I
wonder how many uses of make_tree_vec don't ggcfree their previous tree-vec when using it in a 'realloc' way.

A quick grep for 'make_tree_vec\>' in gcc reveals about 80 uses, many of which with an arithmetic expression as its
argument.  I wonder how many of these might benefit from such an allocation scheme and how many would be impaired by
it?

Maybe its an insignificant issue.

>> +  /* XXX: Maybe to loop rather than recurse here? */
>
> At -O2, the GCC optimizers should convert tail recursion into looping.
>
Great, no worries there then.

>> +  if (type_dependent_expression_p (expr))
>> +    /* TODO: Should defer this until instantiation rather than using
>> +             decltype.  */
>> +    return_type = type_decays_to (non_reference (finish_decltype_type
>> +                  (expr, /*id_expression_or_member_access_p=*/false)));
>
> Definitely need to defer it; type_decays_to and non_reference don't work
> on DECLTYPE_TYPE.
>
I thought as much -- I assume it's just trying to strip non-existent qualifiers from `decltype(expr)' which amounts to
a no-op.

Thanks again for the feedback.  I'll try to get deferred return type deduction working when I get some time.  Working
through that will probably end up sorting some of the issues with dependent return type deduction inside templates.

Cheers,
Adam