On Thu, Aug 6, 2009 at 6:27 AM, Adam Butcher <a...@jessamine.co.uk
<mailto:a...@jessamine.co.uk>> wrote:
I take you're point on [finish_struct_1] potentially being overkill
but at least it means that user programs
that copy can work.
Right. I only added that comment so that other developers who come
along and want to optimize it won't fall into the same trap I did.
I've attached my two diffs made against the latest lambda head.
First is explicit polymorphic lambda support via the
additional template parameter syntax, second is the very hacky
'for-discovery-purposes-only' prototype for typename
inference.
I was hesitant to add the first patch alone, but now that you've got the
second, I'm eager to take another look.
Currently for auto typename inference, cv-qualifiers (and other bits
like attributes) are lost
One thing I'm worried about is that I'm using make_tree_vec() with a
length one greater than that of the previous
vector in order to grow the template parameter list whilst parsing
function arguments.
I'll be sure to look at these issues.
There's a number of things I'm not sure about regarding location of
the implementation (parser.c, semantics.c, decl.c
etc).
The general guideline I followed was to put as much non-parsing logic
into semantics.c as possible, and call into it from parser.c when
needed. I'm not sure what needs to go into decl.c either.
I will try to take this opportunity of renewed interest in the lambdas
branch to look at dependent type support and name mangling. When I say
dependent type support, I mean using lambdas that capture or declare
variables of dependent type from a surrounding template context. Many
people won't be able to effectively use lambdas until these features are
added.
- John
