Am Sonntag, den 23.05.2021, 09:23 +0200 schrieb Jₑₙₛ Gustedt via Liaison:
> on Sat, 22 May 2021 16:54:34 +0000 you ("Uecker, Martin via Liaison"
> <liaison_at_[hidden]socpp.org>) wrote:
>
> > Deprecating volatile on return types seems like a good idea,
>
> Yes, even more, all qualifiers. In C, the qualification is not part of
> the effective return type anyhow, see 6.7.6.3 p4 last sentence. IIRC we
> introduced that in C17 to avoid glitches with `_Generic` and
> observability of types in general.

yes, we should simply deprecate all qualifiers on return types.

> > but on parameters it has a valid uses. I find the suggestion
> > that one can copy those into a new variable not very convincing.
> > It would be another special exception. We should make the
> > language simpler and not more complicated.
> >
> > There is also no reason to include qualifiers in prototypes,
> > so these do not have to leak implementation details. One
> > could consider deprecating all qualifiers on parameters in
> > function declarations that are not part of a function
> > definitions. This would make more sense to me.
>
> So we could do that even larger for parameters and the return type.

One downside is that prototypes then sometimes do not
look identical. And then there are two annoying cases:

Atomics. Those are not qualifiers but a separate type
(a design flaw in my opinion). But it does not really make
sense to have atomic arguments as the values are the same
as for the non-atomic type and you can assign it
to the non-atomic. So in principle, it would make
sense to also deprecate these in prototypes together
with qualifiers.

restrict. This should be visible in the prototype
because it is important information for the caller.
The design flaw here is that restrict
is a qualifier of the pointer and not of the pointer
target.


Martin