Am Mittwoch, dem 08.02.2023 um 23:16 +0200 schrieb Ville Voutilainen:
> On Wed, 8 Feb 2023 at 23:13, Uecker, Martin
> <Martin.Uecker_at_[hidden]> wrote:
> > > > The initial situation may be so that the oddball compiler doesn't
> > > > support the attribute without a warning.
> > > > So there's a need to detect when it stops complaining, but it might
> > > > never change to say "I accept it
> > > > and implement its recommended practice".
> > >
> > > Thank you. I think I get it now: has_attribute needs
> > > to return '1' once the compiler stops complaining
> > > to be able to detect the *change* in behavior.
> > >
> >
> > No sorry. I still don't get it. Even if
> > has_attribute changes from 0 to 202003L or
> > somthing, you would transition from a no warning
> > scenario to another no warning scenario when
> > compiling the project hat uses feature detection.
> >
> > So you still do not get notified about the
> > fact that the odd-ball compiler now does not
> > warn anymore about the attribute.
>
> Notified? Right, you don't get notified, but you can just notice
> yourself that the feature detection is no longer
> needed, so you can clean up your code by removing it.

But noticing youself (by reading release notes or running
a test programm) it is not required that __has_c_attribute
returns non-zero once the compiler starts syntax checking.
It could just continue to return 0.


> And yes, this is a desire of lesser importance and lesser urgency, and
> doesn't need to be a part of __has_c_attribute or __has_cpp_attribute.

Worse, changing __has_c_attribute would not even help here.



Martin