On Fri, Oct 6, 2023 at 9:43 AM Timur Doumler via Liaison
<liaison_at_[hidden]> wrote:
>
> One more technical question:
>
> Here is the bit in the C++ Standard that clarifies that things in [[ ... ]] are *not* token-ignorable:
> http://eel.is/c++draft/dcl.attr.grammar#note-4
>
> Could someone please point me to the corresponding place in the C standard saying that in C, things in [[ ... ]] *are* token-ignorable?
>
> It seems this is a difference between C and C++ that is somewhat relevant for this discussion.

The relevant bits are:

C23 6.7.12p2: Support for any of the standard attributes specified in
this document is implementation-defined and optional. For an attribute
token (including an attribute prefixed token) not specified in this
document, the behavior is implementation-defined. Any attribute token
that is not supported by the implementation is ignored.

C23 6.7.12.1p3: ... A strictly conforming program using a standard
attribute remains strictly conforming in the absence of that
attribute.

C23 Footnote 186: Standard attributes specified by this document can
be parsed but ignored by an implementation without changing the
semantics of a correct program; the same is not true for attributes
not specified by this document.

~Aaron

>
> Cheers,
> Timur
>
> On 6 Oct 2023, at 16:35, Timur Doumler <cpp_at_[hidden]> wrote:
>
> Hi JeanHeyd and everyone,
>
> On 5 Oct 2023, at 19:48, JeanHeyd Meneide via Liaison <liaison_at_[hidden]> wrote:
> ---- (With my chair hat ON) ----
>
> If you'd like to get SG22's opinion Officially™, you are more than welcome to say this is important enough to invite a review by SG22. If you picked the [[ ]] attribute syntax it would be more important for SG22 to review it and give feedback (And at that point I would *insist* upon a review and feedback), but if not and the syntax is in a novel location I don't see how we'd need explicit cooperation. (E.g., when C++11 got static_assert(…), we just handled the syntax difference by having _Static_assert(...) in C and piling an extra keyword in <assert.h>.) Same process that Aaron mentioned before: ugly keyword first, normal keyword later. Nothing either Committee can't handle.
>
>
> Thank you. I believe that it would be very helpful to get SG22' opinion Officially™ in this instance. The reason being that we have a C++ committee meeting soon where we want to decide on the syntax (P2935 or P2961) and for making that decision it would be very helpful to have some feedback from the C committee about which syntax *they* would prefer and why.
>
> So far I have counted four people (Aaron, Niall, JeanHeyd, Jens G) speaking out in favour of the P2961 syntax, and one person (Martin) speaking out in favour of the P2935 (attribute-like) syntax. So it seems that at least this group isn't unanimously in favour of either of the two syntaxes (although the one vote for P2935 was predicated on making contract annotations token-ignorable which is an explicit non-goal for us for C++). So it would be very helpful to have some kind of SG22 poll or decision or record of consensus (or however you do these things!) to say one of three things: "SG22 wants the attribute-like syntax" or "SG22 wants the P296 syntax" or "SG22 is officially undecided".
>
> JeanHeyd, how would we go about inviting a review by SG22, and how long would that take? Our next in-person meeting, where we intend to decide on the syntax, is going to take place in Kona Hawaii on November 6-11, that's one month from now. Is there any chance to get official feedback from SG22 before then?
>
> I greatly appreciate everyone's involvement here to help us get this right. Thank you.
>
> Cheers,
> Timur
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/10/1248.php