* Would you subscribe to the above analysis?

No.

One of them is wrong.

-- Gaby

From: SG21 <sg21-bounces_at_[hidden]> On Behalf Of Andrzej Krzemienski via SG21
Sent: Wednesday, September 22, 2021 11:31 AM
To: Aaron Ballman <aaron_at_[hidden]>
Cc: Andrzej Krzemienski <akrzemi1_at_[hidden]>; WG14/WG21 liaison mailing list <liaison_at_[hidden]>; Nevin Liber via SG21 <sg21_at_[hidden]>
Subject: Re: [isocpp-sg21] [wg14/wg21 liaison] Explain contracts use case cdev.ignorable



śr., 22 wrz 2021 o 20:12 Aaron Ballman <aaron_at_[hidden]<mailto:aaron_at_[hidden]>> napisał(a):
On Wed, Sep 22, 2021 at 8:17 AM Andrzej Krzemienski via Liaison
<liaison_at_[hidden]<mailto:liaison_at_[hidden]>> wrote:
>
> Hi SG21 and SG22,
> I would like to summarize and put more structure into the discussion that we had in another thread.
>
> I would like to start with one use case bought up by Aaron from the "Contract Use Cases" document (P1995r0).

Thanks! I can speak to my opinions on this, but others should
definitely chime in if they have a different opinion/recollection.

> Use case 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
>>
>> Assuming contracts continue to be rendered as attributes, C standardization would require they be semantically optional.
>>
>> Note that, just as with C++, the ':' in the previous contract syntax does not match the grammar for attributes in either language, so by a strict reading of the standards there is no obligation to be ignorable. ('[[a:b]]' is not a valid attribute and should be diagnosed as invalid on any current C or C++ compiler). Many have expressed the view that this opinion is pedantic and that the spirit of the law is that anything between [[]]s should be ignorable.
>>
>> Additionally, it is currently a conforming extension to throw away all tokens between a pair of [[]]s, and there exist numerous compilers that take advantage of that fact which would be broken by requiring behavior of any constructs that look like an attribute.
>
> I have a couple of questions for whoever feels represented by this use case.
>
> Q1. I see a clash between the "In order to" and "I want to" sections. Why does a C developer need "all contract semantics optional" to "write contracts on their function"? Once the contracts are in C, programmers can certainly write their contracts even if the contract semantics are not "optional".
>
> Or is this saying that contracts-enabled C compiler processes the contracts as in P2388R2 and pre-contracts C compiler treats contract annotations as comments?

I suspect this is because the [[]] syntax for contracts looks too
similar to attributes to believe the statement "these aren't
attributes". So there is a belief that these really are attributes (or
functionally close enough to them) and should follow the same design
principles, namely that the program should behave the same in the
absence of the attribute,

Ok, let's do a checkpoint here to see if I understood you.

One person can claim, "[[a:b]] is not an attribute because it does not match the grammar production of an attribute, neither in C nor in C++".
Another person can claim, "[[a:b]] is an attribute because it starts with [[ and ends with ]]".
This results in the situation where there is not one universal answer to the question if [[a:b]] is an attribute.

Would you subscribe to the above analysis?

Regards,
&rzej;

which is in conflict with the design goals
for contracts (e.g., you want to guarantee abort behavior on a
violated contract, that sort of thing).

> Q2. The last paragraph in the above use case says "it is currently a conforming extension to throw away all tokens between a pair of [[]]s". Does n2385 confirm that this is a conforming extension? Or any earlier/later version? Or is it just common practice that is non-conformant?

The latest version of the C2x working draft is WG14 N2596, btw. And
yes, it does confirm this is a conforming implementation (not an
extension) in 6.7.11.1p3 and 5.1.1.3p1.

> I tried to play with GCC and Clang on any versions I could find in the Compiler Explorer (https://godbolt.org/z/PsqP57cs4<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgodbolt.org%2Fz%2FPsqP57cs4&data=04%7C01%7Cgdr%40microsoft.com%7C7cefe084a6a44fea4f5208d97df74a9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637679323343046412%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oGlO5S%2FUsInr2Swhc0zlYJ3C5jBCEfBb2o6c0n1%2FhOs%3D&reserved=0>), and it looks like they either don't parse attributes at all, or report the colon in [[pre: i]] as syntax error.

There was mention of intent to use this strategy by an implementer
when we discussed the adoption of the attribute syntax in WG14. I'm
unaware if they used that strategy or if that compiler is publicly
available.

~Aaron

>
> Regards,
> &rzej;
>
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]<mailto:Liaison_at_[hidden]>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fliaison&data=04%7C01%7Cgdr%40microsoft.com%7C7cefe084a6a44fea4f5208d97df74a9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637679323343056402%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lh3GyH5fCsfJOIbQWvGz9FdIMwh3MfrgNyM%2Fok%2FKSOw%3D&reserved=0>
> Link to this post: http://lists.isocpp.org/liaison/2021/09/0763.php<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fliaison%2F2021%2F09%2F0763.php&data=04%7C01%7Cgdr%40microsoft.com%7C7cefe084a6a44fea4f5208d97df74a9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637679323343056402%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LbIlL7FiXmTAqyh7gylDMio1u7xY6u7w43EuV5laIUs%3D&reserved=0>