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: Andrew Sutton <andrew dot n dot sutton at gmail dot com>
- Cc: Braden Obrzut <admin at maniacsvault dot net>, 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 19:34:49 +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> <08daee2be22f657b687930b459c5629b at imap dot force9 dot net> <CANq5Syu8XUyQkGcYth=N+vb4vjrq8G8FGJ_fcy+KJVFgPqMxow at mail dot gmail dot com>
On 2014-07-28 13:09, Andrew Sutton wrote:
The first and last 'auto' in the line would be resolved by return type
deduction, the second, in the parameter list, would be a synthesized
3) auto (*f (auto)) (auto); // generic function 'f' constrained to
returning a unary function pointer deduced from the return
Really? I've read the comment and I'm still not sure how to read this
E.g. If the function were defined as
auto (*crazy (auto f)) (auto)
then it is only well formed if instantiated with an 'f' that is
convertible to some ptr-to-function type of the form "R (*) (A)". At
which point return type deduction would subst 'R' for the first 'auto'
and 'A' for the last.
If it were passed a pointer to the following function
then it should be instantiated as
int (*crazy (int (*f) (float))) (float)
My point with case (3) is that it contains two function parameter lists
that contain 'auto' but they need to be dealt with differently for
generic function template argument synthesis and for return type
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.
I have a feeling you may be right.
My thinking was going the other way other initially (assuming a
function until you know it isn't). But I think deduced return types
would cause problems with this so I'm thinking the "assume variable"
route might be better. We'd have to generate some form of parametric
type tree for the variable type before deduction from the initializer
anyway and it may be that such a tree could be transformed into the
function type should the decl turn out to be a function.
That is, always parse declarations like variables, and then build up
template parameters as needed during grorkdecl or grokfndecl. Or
that's too late. I don't know.
I recall my initial experience of implementing generic functions: I
tried to work in the grok*decl space, but found that so many cases had
to be handled explicitly and types rebuilt afterwards potentially after
errors about 'auto' had already been issued (which needed additional
cases to avoid). I remember it being nasty. But it was my first hack
on the GCC code base; so that was probably a factor (still is!).
Switching to the parsing route allowed to transform the code on the fly
as if it had been written with the full template header from the start;
making all the existing code happy. I would like to eliminate the
possibility of making the "during parsing" route work before diving back
in to a post-parse solution.
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