śr., 22 wrz 2021 o 20:12 Aaron Ballman <aaron_at_[hidden]> napisał(a):

> On Wed, Sep 22, 2021 at 8:17 AM Andrzej Krzemienski via Liaison
> <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), 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]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2021/09/0763.php
>