LOL. I guess I will have to use the future gnu:: atributes then ;-)

Am Freitag, dem 27.10.2023 um 20:08 +0000 schrieb Cranmer, Joshua:
> No, the naming was never brought up in the discussion.
>
> > -----Original Message-----
> > From: Liaison <liaison-bounces_at_[hidden]> On Behalf Of Martin Uecker
> > via Liaison
> > Sent: Friday, October 27, 2023 16:03
> > To: liaison_at_[hidden]; JeanHeyd Meneide <wg14_at_[hidden]>; Joshua
> > Berne <jberne4_at_[hidden]>; Timur Doumler <cpp_at_[hidden]>
> > Cc: Martin Uecker <ma.uecker_at_[hidden]>
> > Subject: Re: [wg14/wg21 liaison] SG22 meeting - 27th of October, 12:00
> > EDT/18:00 UTC+2
> >
> >
> >
> > Was there a solution for the "pre" and "post" names discussed?
> >
> > Martin
> >
> >
> > Am Freitag, dem 27.10.2023 um 19:50 +0100 schrieb Nina Dinka Ranns via
> > Liaison:
> > > Hello,
> > >
> > > Minutes from today's meeting can be found on the WG21 wiki at
> > > https://wiki.edg.com/bin/view/Wg21telecons2023/Teleconference2023-
> > 10-2
> > > 7 For the benefit of those who are not WG21 members, they have also
> > > been pasted here.
> > >
> > > Do not make the minutes publicly available. Do not quote anyone
> > > without their explicit permission.
> > >
> > > Any questions, please let me know.
> > >
> > > Thank you to everyone who attended, especially the scribes.
> > >
> > > Best,
> > > Nina
> > >
> > > Attendance
> > > Nina Ranns WG21 (chair)
> > > Aaron Ballman WG14 & WG21 (scribe 1)
> > > Marco Foco WG21
> > > Jens Gustedt WG14
> > > Timur Doumler WG21
> > > Joshua Cranmer WG14 & WG21
> > > Walter Brown WG21
> > > Tom Honermann WG21 & WG14
> > > Corentin Jabor WG21 & WG14 (scribe 2)
> > > Joshua Berne WG21
> > > Thomas Koeppe WG21
> > > Ville Voutilainen WG21 & WG14
> > > Jens Maurer WG21
> > > Freek Wiedijk WG14
> > > JeanHeyd Meneide WG14 & WG21
> > >
> > > 2:09hrs start
> > >
> > > Timur: presentation on contracts in general, regarding P2900. Aiming for
> > MVP in C++26. The big question is how to spell contract annotations.
> > "Attribute-like syntax" or "natural syntax".
> > > Want to know if there's interest in standardizing for C, which preference do
> > we have for syntax for C, and any C-specific technical concerns?
> > >
> > > Jens G: terminating, you mean std::terminate, or something else?
> > >
> > > Timur: implementation-defined manner
> > >
> > > Jens: I had the impression that defining contracts would make otherwise-hit
> > UB be actually defined behavior?
> > >
> > > Timur: yes, for the enforce semantics (the ignore or observe semantics
> > > will still get you the UB)
> > >
> > > Jens: but at least one semantic where you cannot ignore?
> > >
> > > Timur: yes
> > >
> > > Timur: presentation of natural syntax (P2961). Cannot use assert as an
> > > identifier because of assert.h, settled on contract_assert (as a full
> > > keyword). Attribute-like syntax is problematic because it looks like an
> > attribute but isn't one. Positioning is awkward. Assert expressions don't
> > actually appertain to anything. Contracts do not follow attribute rules for
> > aggregation, comma-separation, etc. There are also post-MVP extensions that
> > lead to grammar ambiguities in attribute-like syntax (such as with labels).
> > >
> > > Joshua B: Presentation of attribute-like syntax. assert does not
> > > collide with the macro in C because it is not followed by a paren so it's not a
> > function-like macro form. Trailing return types expose more differences
> > between the two syntax choices.
> > >
> > > Nina: is there interest in standardizing contracts in C?
> > >
> > > Jens: Yes, I think this is definitely interesting for C. I would like
> > > to see it. But we go slower than C++, so it may be decades instead of years. It
> > would be nice for C++ compilers to expose this functionality as an extension in
> > C.
> > >
> > > Aaron: echoing what Jens said, contracts in C are important
> > >
> > > Nina: anyone in WG14 thinks contracts would not be a good extension to C?
> > >
> > > Nina: we have an answer to the first question, there is interest in C.
> > >
> > > Joshua C: WG14 might not be interested in all of the aspects of
> > > contracts, as much as WG21 is. Especially some of the extensions post-MVP.
> > But the general idea would be accepted, but maybe more restricted than the
> > C++ version.
> > >
> > > Ville: it's safe to assume that C++ will entertain further extensions than the C
> > committee.
> > >
> > > Nina: what problems does WG14 have with either of the two syntaxes.
> > >
> > > Aaron: strong preference for natural syntax over attributes;
> > > attribute-like syntax makes it hard to determine order of attribute vs
> > contract, contracts aren't really attributes but look like them, etc.
> > >
> > > Jens G: C always wants to preserve user code as the standard evolves;
> > > needs a mechanism to ignore new facilities in older compilers. Natural syntax
> > makes this easier. Could it be a real attribute?
> > >
> > > Nina: Josh B, was that considered?
> > >
> > > Joshua B: it was considered but we don't want contracts to be
> > > ignorable the same way that attributes are; you can wrap either syntax
> > > with a macro if you need to. Even if you macro pre- or
> > > post- as a function-like macro because suddenly you are making a macro
> > > out of something that users already have functions for. Would need to use a
> > reserved identifier to avoid breaking users. Might be a nice to have to have
> > new language features magically work in old compilers, but doesn't make
> > sense to restrict the design for that.
> > >
> > > Freek: Do these annotations change the meaning of the program, right? Not
> > just for external tooling?
> > >
> > > Joshua B/Timur: Yes
> > >
> > > JeanHeyd: using the attribute-like syntax when it's not ignorable can
> > > trip up users who assume unknown attributes are ignored. It's not meant to
> > be an attribute, it's meant to be something stronger, so we should spell it in a
> > way that doesn't look like something that can be ignored. I would strongly
> > encourage to not look like an attribute, in either C or C++.
> > >
> > > Nina: does anyone see a specific problem for C with either of these syntaxes?
> > A technical concern about C vs personal preference.
> > >
> > > JeanHeyd: syntactically, neither should be difficult to add into a
> > > compiler. Not novel constructs in terms of parsing. More that certain forms
> > present certain problems, so that should be considered.
> > >
> > > Aaron: in C, anything between [[]] can be token soup ignored by
> > > implementations -- reaffirmed by WG14
> > >
> > > Jens G: not a severe problem for compilers to implement, but I wasn't
> > > in favor of this syntax for attributes either due to added ambiguities. Adding
> > to that with another meaning for [[]] may introduce new ambiguities. Prefer
> > not to have to do this sort of work.
> > >
> > > Joshua B: confused by token ignorable grammar in C; I can't find it
> > >
> > > Joshua Bern: foo : doesn't mean the grammar of an attribute in either
> > language because the colon makes it not match the grammar, ignoring
> > everything is afaik is not a valid implementation.
> > > We should fix the wording, or the understanding
> > >
> > > Jens M: We heard this may be a bug in the specification of C. in C++, we
> > recently fixed our wording in the other way, and we mandate valid syntax. C is
> > allowed to make a different choice.
> > >
> > > Polls
> > > Would SG22 find it acceptable if SG21 adopts the attribute-like syntax as
> > proposed in P2935 for contracts in C++?
> > >
> > > WG14:
> > >
> > > SF F N A SA
> > >
> > > 0 0 0 4 2
> > >
> > > WG21:
> > >
> > > SF F N A SA
> > >
> > > 0 2 2 6 0
> > >
> > > Would SG22 find it acceptable iif SG21 adopts the natural syntax as
> > proposed in P2961 for contracts in C++?
> > >
> > > WG14:
> > >
> > > SF F N A SA
> > >
> > > 3 1 2 0 0
> > >
> > > WG21:
> > >
> > > SF F N A SA
> > >
> > > 3 6 1 0 0
> > >
> > > On Wed, 25 Oct 2023 at 15:43, Nina Dinka Ranns
> > <dinka.ranns_at_[hidden]> wrote:
> > > > Hi all,
> > > >
> > > > in preparation for the discussion on Friday, these are the questions that the
> > Contracts Study Group would like to get feedback on and the questions we will
> > ask in the call :
> > > >
> > > > 1. Is there interest in standardising Contracts for C in a way that
> > > > is compatible with the Contracts for C++ feature that we are
> > > > currently designing in SG21? (P2900R1)
> > > >
> > > > 2. Is there any preference, from the C perspective, for choosing the
> > > > syntax proposed in P2935R3 ("attribute-like syntax") or the syntax
> > proposed in P2961R1 ("natural syntax") for this feature?
> > > >
> > > > 3. Are there any C-specific technical concerns with either of these two
> > syntax proposals?
> > > >
> > > > See you virtually on Friday,
> > > > Nina
> > > >
> > > >
> > > >
> > > > On Wed, 18 Oct 2023 at 17:53, Nina Dinka Ranns
> > <dinka.ranns_at_[hidden]> wrote:
> > > > > Hi all,
> > > > >
> > > > > we will have an SG22 discussion of the two currently proposed C++
> > > > > Contract syntax options on Friday, the 27th of October at 12:00
> > > > > EDT/17:00 BST/18:00 UTC+2
> > > > >
> > > > > Zoom details :
> > > > >
> > https://iso.zoom.us/j/96163983943?pwd=ZXpTRmVWb0oweGx3b0gwYzBa
> > eEdq
> > > > > Zz09
> > > > >
> > > > > You should be able to join via the link without a passcode. I will send the
> > passcode in a separate email.
> > > > > Please do not publicly share the link as this is an ISO meeting and only
> > open to the ISO members.
> > > > >
> > > > > Whether you already gave feedback on this mailing list or not, we
> > > > > would appreciate your participation in the meeting. It allows us to better
> > reflect the views and opinions of SG22 members (more specifically, those
> > involved in WG14), and to get a more accurate feeling of what the group
> > thinks.
> > > > >
> > > > > The papers we will discuss are :
> > > > > https://isocpp.org/files/papers/P2935R3.pdf
> > > > >
> > > > > https://isocpp.org/files/papers/P2961R1.pdf
> > > > >
> > > > > Any questions, please let me know.
> > > > >
> > > > > Best,
> > > > > Nina
> > > _______________________________________________
> > > 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/1330.php
> >
> > _______________________________________________
> > 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/1332.php