Re: Patch for constexpr variable templates

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

On 2014-07-28 3:06, Braden Obrzut wrote:
> So given this, should I leave the test cases that fail for this
> reason alone or should I still change them to dg-message?
I'm not sure what GCC's policy is here, Jason will.

> 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.  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.

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.

Ever since generic functions were implemented, (2) has always
been seen as an attempt to declare a variable template.
Previously we've thrown these out.  As your patch now allows
them, it seems like something should be done here prior to a
final solution of fixing the behavior.  Maybe marking as
expected failures would be OK for now then raising a new
issue to address this properly.  Jason, what do you think?

Adam