Apologies, I intended to Cc Aaron Ballman, but instead accidentally Cc'ed SG1 (concurrency).

SG1: apologies for the noise.

Aaron: I now added you, please see message below.

Cheers,
Timur

> On 7 Feb 2023, at 10:50, Timur Doumler via Core <core_at_[hidden]> wrote:
>
> Hi EWG, CWG, and SG22,
>
> EWG took the following polls yesterday:
>
> Poll 0.1: The semantic ignorability of standard attributes in general should be explicitly stated in the C++26 standard.
> SF/F/N/A/SA 8/18/1/2/0
> Consensus.
>
> Poll 0.2: The semantic ignorability of standard attributes in general should be explicitly stated in a standing document.
> SF/F/N/A/SA 3/3/10/6/4
> Not consensus.
>
> Poll 1: C++26 should specify that __has_cpp_attribute should return a positive value for a standard attribute only of it implements the semantics suggested in the specification of the attribute (such as in "Recommended practice").
> SF/F/N/A/SA 4/9/2/9/7 Consensus against.
>
> Poll 2: C++26 should more clearly specify that __has_cpp_attribute should return a positive value for a standard attribute if the implementation can properly parse/check it, even if it does not implement any semantics.
> SF/F/N/A/SA 9/7/8/2/1
> Consensus for.
>
> So we now have direction to add the two things from the two polls highlighted in bold above.
>
> I just wrote a first draft of the wording for this. Since EWG felt that both of the additions do not actually change the status quo, but only constitute desirable clarifications, I put them into Notes:
>
> [dcl.attr.grammar]/6:
>
> For an attribute-token <http://eel.is/c++draft/dcl.attr#nt:attribute-token> (including an attribute-scoped-token) not specified in this document, the behavior is implementation-defined; any such attribute-token that is not recognized by the implementation is ignored.
> [Note 4: A program is ill-formed if it contains an attribute <http://eel.is/c++draft/dcl.attr#nt:attribute> specified in [dcl.attr] that violates the rules specifying to which entity or statement the attribute can apply or the syntax rules for the attribute's attribute-argument-clause, if any. — end note]
> [Note 5: The attributes specified in [dcl.attr] have optional semantics: given a well-formed program, removing all instances of a particular attribute specified in [dcl.attr] results in a program whose observable behaviour is a conforming realisation of the original program. — end note]
>
> [cpp.cond]/6:
>
> For an attribute specified in this document, the value of the has-attribute-expression is given by Table 22. For other attributes recognized by the implementation, the value is implementation-defined. <http://eel.is/c++draft/cpp.cond#6.sentence-2>
> [Note 1: It is expected that the availability of an attribute can be detected by any non-zero result. <http://eel.is/c++draft/cpp.cond#6.sentence-3> Availability of an attribute specified in [dcl.attr] implies that the rules specifying to which entity or statement the attribute can apply and the syntax rules for the attribute's attribute-argument-clause, if any, are verified, but does not imply availability of its optional semantics. — end note]
>
> @EWG+CWG: Does this look good? Is there anything that can be improved in the wording draft above?
>
> Meanwhile, new information has been brought to my attention since my presentation yesterday. It seems that Poll 2 / the second green blob does not match what C intends to do. There, apparently the intention is that __has_c_attribute should only return a positive value if the compiler actually implements the semantics of an attribute in some "useful" or "observable" way, for some definition of "useful" and "observable" (Poll 1), not just if the compiler can recognise and parse it but then do nothing else with it (Poll 2).
>
> @SG22: Can you confirm this? What is the intent of __has_c_attribute in C: what Poll 1 says or what Poll 2 says?
>
> If it's what Poll 1 says, then it seems that we would be introducing a new divergence between C and C++ here, which would be unfortunate. Simultaneously, it was my impression yesterday that EWG thinks Poll 1 is not a reasonable or feasible direction, as we have no way of defining what those "useful" or "observable" semantics would be that are required for __has_cpp_attribute to return a positive value in the Poll 1 scenario.
>
> How should we resolve this contradiction? Should we re-discuss that aspect of the paper in EWG, with someone from SG22 present?
>
> Thanks,
> Timur
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2023/02/13835.php