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
