This is the mail archive of the
mailing list for the GCC project.
Re: Patch for constexpr variable templates
- From: Adam Butcher <adam at jessamine dot co dot uk>
- To: Braden Obrzut <admin at maniacsvault dot net>
- Cc: Andrew Sutton <andrew dot n dot sutton at gmail dot com>, Jason Merrill <jason at redhat dot com>, Ed Smith-Rowland <3dw4rd at verizon dot net>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 28 Jul 2014 08:33:30 +0100
- Subject: Re: Patch for constexpr variable templates
- Authentication-results: sourceware.org; auth=none
- References: <53CCFBEF dot 9080804 at verizon dot net> <53CDD522 dot 9040508 at maniacsvault dot net> <53D172E4 dot 9020902 at redhat dot com> <53D242FD dot 70002 at maniacsvault dot net> <53D2CB20 dot 1090201 at redhat dot com> <53D352F7 dot 7040402 at maniacsvault dot net> <53D3D34A dot 9080009 at redhat dot com> <53D3D3D9 dot 9000102 at redhat dot com> <0d580e6525100d13a49b2c9327c727f8 at imap dot force9 dot net> <CANq5SytLmkHuCF916K_QG31PTovq1Hir5Q76dJmY8Zce76R0Cg at mail dot gmail dot com> <280a4c80527b753476c274f90ab92fa6 at imap dot force9 dot net> <53D5B03D dot 1010300 at maniacsvault dot net>
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?