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?

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?


> >
> > 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
>