And I forgot to add:

On Mon, Sep 20, 2021 at 1:49 PM Aaron Ballman <aaron_at_[hidden]>
wrote:

> On Mon, Sep 20, 2021 at 12:36 PM Ryan McDougall
> <mcdougall.ryan_at_[hidden]> wrote:
> >
> > Can you help me understand the concern here -- is it that C will have to
> update its grammar to recognize this syntax as not ignorable, and they
> would rather not?
>
> I am raising a concern as a liaison with WG14 who was the one that
> standardized [[]] syntax in that committee. During those discussions,
> we had a *lot* of debate over the syntax and the semantics of the
> feature, but one of the concerns that was raised by an implementer was
> their requirement that attributes be "ignorable" as they are in C++.
> They have implementation burdens with nonignorable attributes for some
> of their implementations and they very much appreciated the discussion
> in WG21 N2761 about the design intent of when it's appropriate to use
> an attribute vs other syntax. To save people effort, a key point from
> that paper was:
>
> "After the meeting in Toronto, we added specific guidance on the
> choice of when to use an attribute to avoid misuse. There was general
> agreement that attributes should not affect the type system, and not
> change the meaning of a program regardless of whether the attribute is
> there or not."
>
> The current proposal changes the meaning of code when the contract
> attribute is not present. Further, that document gives some advice on
> when it's reasonable to use an attribute vs another syntax, and one
> explicit point on when to not use an attribute is "The feature is a
> central part of the declaration that significantly affects its
> requirements/semantics" and the whole point to contracts is to
> significantly affect the requirements of a call.
>
> I mentioned earlier in the thread how they indicated their
> implementations were going to work (eat tokens between [[ and ]] with
> a generic diagnostic), and the syntax used for contracts would cause a
> problem for that sort of implementation strategy. So I'm raising that
> issue because I'm concerned that the non-ignorable nature of this
> attribute-like syntax is going to generate pushback, as happened
> during C++20. I can try to go into more detail of how I understood the
> implementer's concerns, but I don't think that needs relitigation. The
> concerns were sufficient to cause WG14 to request changes to the
> proposal and so I think we should trust the concerns are valid.
>
> (Additionally, I have personal reservations about the syntax chosen,
> but I want to keep that discussion separate so there's hopefully less
> confusion about what's a liaison concern and what's not.)
>
> > On Mon, Sep 20, 2021 at 8:02 AM Aaron Ballman via SG21 <
> sg21_at_[hidden]> wrote:
> >>
> >> On Mon, Sep 20, 2021 at 10:36 AM John Spicer <jhs_at_[hidden]> wrote:
> >> >
> >> > The contracts syntax is intentionally “attribute-like” but “not
> actually an attribute”, which allows a compiler to treat those differently.
> >>
> >> Never have I ever found a user who thinks that explanation holds
> >> water. As an implementer, I've asked dozens of people, and they
> >> uniformly say "stuff between [[]] is an attribute", and indeed, the
> >> original contracts proposal even calls them "contract attributes" and
> >> lists them under the Attributes section of the standard.
> >>
> >> (This is treading well-trodden ground we don't need to re-cover here.)
> >>
> >> > But the syntax difference is very subtle and a different that a
> compiler that does not support attributes would be unlikely to check for.
> >> >
> >> > As an example:
> >> >
> >> > [[something x]]
> >> > [[something(x)]]
> >> >
> >> > The first is an invalid attribute but we could potentially decide to
> make it a contract, while the second is a valid attribute.
> >> >
> >> > So, C++ is saying that the syntax of the stuff inside “[[ ]]” matters
> in the contract vs. attribute decision.
> >> >
> >> > I believe that is intentional so that older C++ compilers that
> support attribute but not contracts will probably ignore them.
> >> >
> >> > I think that also means that unless a C compiler does syntax checking
> on unrecognized attributes, there should not be an issue.
> >>
> >> There are compilers for which the implementation strategy for all
> >> attributes is to note the [[ that opens an attribute specifier, eat
> >> all balanced tokens up to the closing ]], and diagnose the entire bit
> >> as "attribute ignored" (as a warning). You cannot do that with
> >> contracts because a correct program does not remain correct when the
> >> contract is ignored. A program can correctly rely on the contract
> >> violation handler executing, and that's not the case with this
> >> implementation strategy.
> >
> >
> > A correct program is correct regardless of whether its contract is doing
> runtime checking. Are you saying that an *incorrect* program cannot rely on
> its violation handler running when it is compiled as a C program? Would
> that not mean that all C programs have their contract checking turned off?
> >
> >> > All of that said, making progress on contracts is an important and
> also difficult process, and I don’t want to have to guess which other
> groups might have concerns about our direction.
> >> >
> >> > So, if SG21’s work is of concern to SG22, please make sure that
> someone is monitoring and or attending our meetings.
> >>
> >> I can certainly ask SG22 members to attend SG21 meetings if they're
> >> interested in the topic. However, it's a pretty tall order to expect
> >> someone to sign up to fight this level of apathy for the SG22 mandate
> >> when the SG21 answer to "I want to Specify contracts in a way
> >> standardizable as part of the C language" is 3:1 saying it's not
> >> important.
> >>
> >> ~Aaron
> >
> >
> > I think everyone wants the C/C++ compatibility story to be as good as
> possible, but can you outline for us the actual damage?
> >
> > I may be misunderstanding, but to me it seems like you'd rather C++ wait
> to get a harmonized contract syntax, rather than C++ users get a syntax for
> C++23 and force C to catch up?
>
> As a liaison activity, I want to ensure that C++ picks a contract
> syntax that is as likely to get potential (eventual) adoption into C
> as we can find. My fear is that we'll pick the currently proposed
> syntax and that will effectively either prevent adoption into C (too
> unpalatable, we'd rather have nothing) or will be adopted with
> incompatible syntax (WG21 goes with [[]] and WG14 goes with
> _Pre/_Post), and then users are the ones who lose.
>

I think the concern is that we had an explicit goal of getting the subset
of C++20 contracts that were uncontroversial, so programmers and tool
writers could begin developing with a real syntax in place -- and frankly I
think syntax is the least interesting part of any proposal.

I don't think we want to have an unbounded round-trip into a discussion
about syntax without a real objection, or without a credible possibility
we'd end up with something other than what we have today. Not wanting to
look for a colon before eating all things in between [[ and ]] doesn't
appear to me to be something worth keeping contracts out of the language
for another 3-year cycle or more.


> If SG21 thinks this is the syntax that should be standardized, that's
> fine, but then please get some explicit buy-in with WG14 on it because
> this is shared design space. WG21 makes this request from time to
> time. The latest example I can think of is EWG explicitly requesting
> input from WG14 on delimited escape sequence syntax before they felt
> comfortable with moving forward on P2290R1 for C++23. They didn't
> require WG14 to adopt the same feature at the same time, or even adopt
> the feature at all. They mostly wanted to know that if WG14 was going
> to adopt something to perform that functionality, the syntax chosen by
> WG21 was not known to be a nonstarter in WG14. I think contracts are
> sufficiently important and the syntax chosen is known to be
> potentially troublesome enough to warrant the same sort of
> consideration.
>
> ~Aaron
>

I think that sounds like a great liaison activity. Can you lead it? In the
meantime do we need to halt development of contracts for this activity to
take place?

Cheers,


> >
> >>
> >> >
> >> > Thanks,
> >> >
> >> > John.
> >> >
> >> > > On Sep 20, 2021, at 10:12 AM, Aaron Ballman <aaron_at_[hidden]>
> wrote:
> >> > >
> >> > > On Mon, Sep 20, 2021 at 9:54 AM John Spicer via SG21
> >> > > <sg21_at_[hidden]> wrote:
> >> > >>
> >> > >> My personal opinion is that there are SG22 people involved in SG21
> and the should bring forward their concerns they might have.
> >> > >
> >> > > FWIW, I raised some concerns I had when we were early in the process
> >> > > of discovering people's concerns. I've since had to step back from
> >> > > SG21 participation and haven't been able to follow along, but P1995
> >> > > did not give me much hope.
> >> > >
> >> > >
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#cdev.ignorable
> >> > > As a C Developer
> >> > > In order to Write contracts on my functions
> >> > > I want to Make all contract semantics optional (so as not to change
> >> > > WG14-N2385 6.7.11 p2)
> >> > >
> >> > > Must Have: 3, Nice to Have: 3, Not Important: 23 , No Answer: 1
> >> > >
> >> > >
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1995r0.html#cdev.contracts
> >> > > As a C Developer
> >> > > In order to Write contracts on my functions
> >> > > I want to Specify contracts in a way standardizable as part of the
> C language
> >> > >
> >> > > Must Have: 2, Nice to Have: 6, Not Important: 21 , No Answer: 1
> >> > >
> >> > > It seems to me like there's a reason for SG22 to be involved given
> >> > > that C has the same [[]] syntax that C++ has and likely has opinions
> >> > > on designs in that space that are incompatible with their
> >> > > expectations.
> >> > >
> >> > >> The authors have already been working on wording.
> >> > >>
> >> > >> IMO, the SG22 impact is not any greater than it was for the C++20
> contracts proposal, so if they didn’t have problems with that, they
> shouldn’t have concerns now.
> >> > >
> >> > > SG22 was formed after C++20, so there was no official study group
> >> > > stance on the proposal at that time. However, compatibility with C
> was
> >> > > one of the reasons I voted strongly against contracts in C++20 and
> >> > > helped push me to form SG22 in the first place. My (admittedly fast
> >> > > and not thorough) reading of P2388R0 has the same concerns as
> before.
> >> > > I think getting the SG22 perspective would be useful in hopefully
> >> > > avoiding future NB comments, especially because those can arrive
> >> > > through other committees than WG21.
> >> > >
> >> > > ~Aaron
> >> > >
> >> > >>
> >> > >> John.
> >> > >>
> >> > >>> On Sep 20, 2021, at 9:18 AM, Peter Brett <pbrett_at_[hidden]>
> wrote:
> >> > >>>
> >> > >>> Hi all,
> >> > >>>
> >> > >>> Please at least get outline approval from SG22 for the syntax
> before proceeding to spend time writing wording.
> >> > >>>
> >> > >>> Best regards,
> >> > >>>
> >> > >>> Peter
> >> > >>>
> >> > >>>> -----Original Message-----
> >> > >>>> From: SG21 <sg21-bounces_at_[hidden]> On Behalf Of John
> Spicer via SG21
> >> > >>>> Sent: 13 September 2021 11:06
> >> > >>>> To: SG21 - Contracts <sg21_at_[hidden]>
> >> > >>>> Cc: John Spicer <jhs_at_[hidden]>
> >> > >>>> Subject: [isocpp-sg21] Telecon to review P2388R1 Minimum
> Contract Support:
> >> > >>>> either Ignore or Check_and_abort
> >> > >>>>
> >> > >>>> EXTERNAL MAIL
> >> > >>>>
> >> > >>>>
> >> > >>>> We’d like to have a telecon to discuss this paper.
> >> > >>>>
> >> > >>>> We are thinking about either Tuesday 9/21, 9/28, or 10/5 at 8 AM
> Pacific
> >> > >>>> time.
> >> > >>>>
> >> > >>>> Please indicate your preference at this Doodle page:
> >> > >>>>
> >> > >>>>
> https://urldefense.com/v3/__https://doodle.com/meeting/participate/id/mbkZ7Z
> >> > >>>> 6a__;!!EHscmS1ygiU1lA!S7mTfbNuJm-ECRyonHAxUX-
> >> > >>>> WCICkzN9Bo8PvtmHnnslnt0YaN8QUMTi3OMtKqw$
> >> > >>>>
> >> > >>>> Thanks,
> >> > >>>>
> >> > >>>> John Spicer
> >> > >>>> SG21 Contracts Chair
> >> > >>>> _______________________________________________
> >> > >>>> SG21 mailing list
> >> > >>>> SG21_at_[hidden]
> >> > >>>> Subscription:
> >> > >>>>
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg
> >> > >>>> 21__;!!EHscmS1ygiU1lA!S7mTfbNuJm-ECRyonHAxUX-
> >> > >>>> WCICkzN9Bo8PvtmHnnslnt0YaN8QUMThM7kehDA$
> >> > >>>> Searchable archives:
> >> > >>>>
> https://urldefense.com/v3/__http://lists.isocpp.org/sg21/2021/09/index.php__
> >> > >>>> ;!!EHscmS1ygiU1lA!S7mTfbNuJm-ECRyonHAxUX-
> >> > >>>> WCICkzN9Bo8PvtmHnnslnt0YaN8QUMTi7_Om32Q$
> >> > >>
> >> > >> _______________________________________________
> >> > >> SG21 mailing list
> >> > >> SG21_at_[hidden]
> >> > >> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> >> > >> Link to this post: http://lists.isocpp.org/sg21/2021/09/1168.php
> >> >
> >> _______________________________________________
> >> SG21 mailing list
> >> SG21_at_[hidden]
> >> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> >> Link to this post: http://lists.isocpp.org/sg21/2021/09/1180.php
>