Hello,

Minutes from today's meeting can be found on the WG21 wiki at
https://wiki.edg.com/bin/view/Wg21telecons2023/Teleconference2023-10-27
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 <https://wg21.link/p2900r1>)
>
> 2. Is there any preference, from the C perspective, for choosing the
> syntax proposed in P2935R3 <https://wg21.link/p2935r3> ("attribute-like
> syntax") or the syntax proposed in P2961R1 <https://wg21.link/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=ZXpTRmVWb0oweGx3b0gwYzBaeEdqZz09
>>
>> 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
>>
>