This is the mail archive of the
mailing list for the GCC project.
Re: [C++ Patch] Remove is_auto_or_concept, etc
- From: Adam Butcher <adam at jessamine dot co dot uk>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc at gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Tue, 16 May 2017 20:36:08 +0100
- Subject: Re: [C++ Patch] Remove is_auto_or_concept, etc
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <CADzB+2mMey32GGAYdoZ_-stUd_iXwGDi6CaQM9EL-=vpgoy85Q@mail.gmail.com>
Sorry for not getting back to your original post Paolo. I haven't been
picking up mails for a while.
On 2017-05-01 16:56, Jason Merrill wrote:
On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini
On 26/04/2017 12:32, Paolo Carlini wrote:
in 2013 (2013-09-16) Adam added two slightly obscure functions and I
find much around in terms of rationale, etc:
is_auto_or_concept (const_tree type)
type_uses_auto_or_concept (tree type)
I don't think they were there in the original 2009 version on the old
lambdas branch -- but it stagnated somewhat and when I remade it against
mainline (4.something) it was around the time that concepts were showing
similar semantics (in terms of implicit/abbrievated templates). I made
a cardinal sin and introduced an overly-generic function name expecting
that a future concepts implementation would need to trigger at the same
point of the parse too. I.e. if a concept name or 'auto' is seen we
inject an implicit template parameter (or make the "plain" function into
a template at that point).
That intent was not well documented or published (other than in the API
name) and, since -fconcepts is now working without any calls to this
function, it's clearly not been necessary or has been more naturally
done in a different way.
The latter seems completely unused (it's meant for debugging
Quite possibly for debugging though maybe some refactoring got rid of
the need for it and neglected to bin it.
the former evidently simply forwards to is_auto, and we end up in the
front-end with uses of both, which in fact are equivalent, which
weird: IMHO, if they are actually equivalent in our implementation we
clearly explain that in the comment and have only one. Or what?
... replying to myself, in practice we could do the below, which
passes testing, and in fact now seems to me even more obvious than I
a couple of days ago...
Definitely OK to bin. No point in having dead or confusing code; it's
complicated enough as it is. :)