Date: Fri, 27 Oct 2023 22:03:11 +0200
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-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)
> >
> > 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=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
> _______________________________________________
> 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
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-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)
> >
> > 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=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
> _______________________________________________
> 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
Received on 2023-10-27 20:03:17