No, the naming was never brought up in the discussion.

> -----Original Message-----
> From: Liaison <liaison-bounces_at_lists.isocpp.org> On Behalf Of Martin Uecker
> via Liaison
> Sent: Friday, October 27, 2023 16:03
> To: liaison_at_lists.isocpp.org; JeanHeyd Meneide <wg14_at_soasis.org>; Joshua
> Berne <jberne4_at_[hidden]>; Timur Doumler <cpp_at_timur.audio>
> Cc: Martin Uecker <ma.uecker_at_[hidden]l.com>
> 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_googlemail.com> 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_lists.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/10/1332.php