This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
- From: Jason Merrill <jason at redhat dot com>
- To: Adam Butcher <adam at jessamine dot co dot uk>
- Cc: Gcc Patches <gcc-patches at gcc dot gnu dot org>, daniel dot kruegler at googlemail dot com, Volker Reichelt <reichelt at gcc dot gnu dot org>
- Date: Thu, 10 Oct 2013 22:26:14 -0400
- Subject: Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.
- Authentication-results: sourceware.org; auth=none
- References: <08a6b60986417d8ab134b6aa85ecd80e at imap dot force9 dot net> <5254CF91 dot 500 at redhat dot com> <0c2ee45ea87bab94392e93f3a7b20d90 at imap dot force9 dot net>
On 10/10/2013 04:45 PM, Adam Butcher wrote:
Of course; makes sense. I had confused myself. Not that it's a
function parameter pack, but presumably you would expect
auto f(tuple<auto...> p)
to be supported?
That makes sense, though it's a (further) extension.
Can we put this in cp_parser, invert the sense of the flag, and only
set it during cp_parser_parameter_declaration_clause?
Done. But it still needs a flag to disable in the case of explicit
template specialization.
Can't you just check processing_specialization?
Jason