>> It sounds like GCC's behavior with auto in function parameters >> needs to be changed, but that definitely sounds like a separate >> patch to me. >> > I think so. It's definitely a different patch.
Agreed. > I've been > thinking about a simple way for your patch to add to the > constraints for 'auto_is_implicit_function_template_parm_p' in > 'cp_parser_parameter_declaration_clause' but this is happening > incrementally at parse time and I can't see how to distinguish > between the following 'auto' parameters: > > 1) auto f(auto); // generic function 'f'; transformed into > template by 'auto' in parameter list. > 2) auto (*f) (auto); // plain variable 'f' (should have an > initializer for deduction of 'auto's. > 3) auto (*f (auto)) (auto); // generic function 'f' constrained to > returning a unary function pointer deduced from the return expression. Really? I've read the comment and I'm still not sure how to read this declaration. > Ultimately, the last two would require the generalized 'auto' > type deduction behavior. The difficulty is that there doesn't > appear to be any existing means for determining, at parse time > of the first "(auto", whether we're forming a function or > variable declaration. Maybe such state would fall out of a > generalized 'auto' solution. I was wondering about this on the drive to work this morning. Maybe trying to pin down semantics at parse time isn't the right approach. That is, always parse declarations like variables, and then build up template parameters as needed during grorkdecl or grokfndecl. Or maybe that's too late. I don't know. Whatever the solution for auto, it will be the same for concepts. We'll just add constraints to the auto-type whenever we find a constrained-type-specifier. Andrew
