This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch] Remove is_auto_or_concept, etc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]