A DR would impact C++20 implementations. Any impact on older implementations would be at the discretion of the implementation.

John Spicer

> On Nov 12, 2022, at 11:37 AM, Aaron Ballman <aaron_at_[hidden]> wrote:
>
> EWG forwarded a resolution to issue 2538 (Can standard attributes be
> syntactically ignored?) to core as a resolution for GB-055 that is up
> for plenary vote today.
>
> As mentioned on the reflectors and during the EWG discussions of this,
> there is sustained implementer opposition to adopting this resolution.
> At least one C++ implementation (Clang) has stated that we are
> unlikely to implement this proposal as a matter of practicality --
> over the past ten years we've added support for over 400 attributes
> under the model of syntactic ignorability and changing our
> implementation strategy at this point would incur significant risk for
> extremely marginal benefit.
>
> We are also concerned that EWG did not adequately consider the C and
> C++ compatibility issues adopting this proposal will introduce given
> that attributes predominately appear in header files. WG14 spent about
> three years considering this feature aiming to be compatible with C++
> and concluded that "ignored" meant syntactic ignorability. This
> property was critical for at least some C implementations as well.
> While there is time for NB comments against C to change the
> specification, we do not think it is prudent to expect WG14 to change
> direction without stronger motivation.
>
> Further, we are not convinced the effects of this paper are in the
> best interests of users. The result of voting in favor of this
> proposal is for this code to be diagnosed in C++11 mode:
>
> [[deprecated("this has a reason")]] int foo;
> [[nodiscard("this also has a reason")]] int func();
>
> because this proposes, as a DR, to require an implementation to
> diagnose the syntactic violation of providing an attribute argument
> list when the grammar does not allow one for these attributes in that
> language mode.
>
> Adopting a proposal aiming to improve code portability when there are
> expected implementer vetoes and a known incompatibility with C and
> previous versions of C++ does not seem like it will achieve the goal
> of improving code portability. As such, we recommend rejecting this
> proposal during plenary.
>
> ~Aaron