This is the mail archive of the
mailing list for the GCC project.
Re: [C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "gcc at gnu dot org" <gcc at gnu dot org>, Adam Butcher <adam at jessamine dot co dot uk>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 1 May 2017 11:56:19 -0400
- Subject: Re: [C++ Patch] Remove is_auto_or_concept, etc (Was: Re: [C++, concepts] Two slightly obscure pt.c functions?)
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org>
On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini <email@example.com> wrote:
> Hi again,
> On 26/04/2017 12:32, Paolo Carlini wrote:
>> in 2013 (2013-09-16) Adam added two slightly obscure functions and I can't
>> find much around in terms of rationale, etc:
>> /* Returns true iff TYPE is a TEMPLATE_TYPE_PARM representing 'auto',
>> 'decltype(auto)' or a concept. */
>> is_auto_or_concept (const_tree type)
>> return is_auto (type); // or concept
>> /* Returns the TEMPLATE_TYPE_PARM in TYPE representing a generic type
>> (`auto' or
>> a concept identifier) iff TYPE contains a use of a generic type.
>> NULL_TREE otherwise. */
>> type_uses_auto_or_concept (tree type)
>> return find_type_usage (type, is_auto_or_concept);
>> The latter seems completely unused (it's meant for debugging purposes?);
>> 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 seems
>> weird: IMHO, if they are actually equivalent in our implementation we should
>> clearly explain that in the comment and have only one. Or what?
> ... replying to myself, in practice we could do the below, which certainly
> passes testing, and in fact now seems to me even more obvious than I thought
> a couple of days ago...