Re: C/C++ PATCH to add __typeof_noqual (PR c/65455, c/39985)

[Martin Sebor <msebor at gmail dot com>]

On 06/28/2017 10:09 AM, Joseph Myers wrote:
> On Wed, 28 Jun 2017, Martin Sebor wrote:
>
> > > that defines "remove qualifiers except"
> > > operations for every combination of qualifiers in that version of the
> > > compiler (because "remove qualifiers except _Atomic" and "remove
> > > qualifiers except address spaces" cannot be composed into "remove
> > > qualifiers except _Atomic and address spaces, and "remove const, volatile,
> > > restrict and address spaces" is not something user code should need to
> > > hardcode when the intent is "remove qualifiers except _Atomic").
> >
> > I'm not sure I understand what you're trying to say.  I thought
> > we agreed earlier that __typeof_noqual__ would remove all type
> > qualifiers.
>
> Yes, it should.
>
> What I'm saying is: if you provide an interface that enables users to
> write code that means "remove const" and will continue to mean exactly
> that with future GCC versions, even when those versions have additional
> qualifiers, you should also provide an interface that enables users to
> write code that means "remove all qualifiers except _Atomic and address
> spaces" (and likewise for any other combination) and will continue to mean
> exactly that with future GCC versions, even when those versions have
> additional qualifiers.  Allowing users to write "remove const, volatile
> and restrict" is *not* the same, as the meanings would diverge when future
> qualifiers are added.

I see.  That seems reasonable, though more advanced than what
I was envisioning (or what has been requested in either of the
two bugs in the subject).

I don't think there is an equivalent, dedicated trait in C++ to
do that either.  One would have to be composed of the lower-level
ones.  There also is no trait that would remove all type qualifiers
(including extensions), or even traits for querying extensions.
So (AFAIK) there is no way in C++ to do exactly what you described.
That of course doesn't mean that it doesn't make sense, just that
it's too advanced even for C++ despite its highly evolved support
for generic programming.  I would suggest that although providing
something like it would be nice, its absence shouldn't stand in
the way of defining the more limited interfaces first.

Martin