[C++ Patch] Remove is_auto_or_concept, etc

Adam Butcher adam@jessamine.co.uk
Tue May 16 19:36:00 GMT 2017


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 
> <paolo.carlini@oracle.com> wrote:
>> 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:
>>> 
>>> 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 
>>> purposes?);
>>> 

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 
>>> 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...
>> 

Definitely OK to bin.  No point in having dead or confusing code; it's 
complicated enough as it is.  :)



More information about the Gcc mailing list