Date: Mon, 20 Sep 2021 11:00:15 -0400
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.
> 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
>
> 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
>
>
> 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.
> 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
>
> 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
>
Received on 2021-09-20 10:02:05