C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] [isocpp-sg21] Telecon to review P2388R1 Minimum Contract Support: either Ignore or Check_and_abort

From: Andrzej Krzemienski <akrzemi1_at_[hidden]>
Date: Tue, 21 Sep 2021 17:20:59 +0200
pon., 20 wrz 2021 o 18:42 Gabriel Dos Reis via SG21 <sg21_at_[hidden]>
napisaƂ(a):

> > Perhaps we should explain this better in our Contracts proposal, in
> > its rationale part. :)
>
> I agree it is an FAQ by now - after 6 years.
>
> By the way: [[assert: condition]] vs. [[assert(condition)]]. One is
> predictable, the other isn't.
>

What do you mean here? Is it that the former cannot be ignored as an
unrecognized attribute?

Regards,
&rzej;

>
> -- Gaby
>
>
> -----Original Message-----
> From: SG21 <sg21-bounces_at_[hidden]> On Behalf Of Ville Voutilainen
> via SG21
> Sent: Monday, September 20, 2021 7:47 AM
> To: SG21 <sg21_at_[hidden]>
> Cc: Ville Voutilainen <ville.voutilainen_at_[hidden]>; Aaron Ballman via
> Liaison <liaison_at_[hidden]>
> Subject: Re: [isocpp-sg21] Telecon to review P2388R1 Minimum Contract
> Support: either Ignore or Check_and_abort
>
> On Mon, 20 Sept 2021 at 17:36, John Spicer via SG21
> <sg21_at_[hidden]> wrote:
> >
> > The contracts syntax is intentionally "attribute-like" but "not actually
> an attribute", which allows a compiler to treat those differently.
> >
> > 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.
>
> But the whole point of choosing an attribute-like but
> not-exactly-attribute syntax is to have the contract declaration
> be ill-formed if the compiler doesn't understand it. The contract
> declaration refers to language constructs declared
> in the program, and it's desirable to have the compiler syntax-check
> them even if they're not evaluated by the
> program. The rationale for that is that if checking is enabled, the
> contracts are well-formed, but also that even
> if checking is disabled, the contracts are still well-formed to have
> any hope for other tools being able to make any
> sense of them. Consider
>
> [[pre: greater_than_zero(x)]] // you must have a convertible_to_bool
> greater_than(convertible_from_int) function in your program
> void f(int x);
>
> [[precondition,the,value,of,x,is,greater,than,zero]] // no particular
> requirement that you have anything in your program
> void f(int x);
>
> Yes, the second example is rather concocted. But its purpose is to
> illustrate what we could get if we go for
> an attribute syntax that the compiler can happily ignore. Now we have
> a contracty declaration that is no contract
> at all, and a static checking tool has no chance of knowing that it is
> a contract declaration. A compiler could
> balanced-token ignore it and fail to tell the programmer that what was
> intended to be a contract declaration
> is no such thing.
>
> Perhaps we should explain this better in our Contracts proposal, in
> its rationale part. :)
> _______________________________________________
> SG21 mailing list
> SG21_at_[hidden]
> Subscription:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg21&amp;data=04%7C01%7Cgdr%40microsoft.com%7C40944c682e8b4253e33408d97c459014%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637677460488643091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gLb4ZLtdSm4KHel5LW9aCgC%2Bc%2BwxJx3cug%2FZsCcCUqU%3D&amp;reserved=0
> Link to this post:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fsg21%2F2021%2F09%2F1178.php&amp;data=04%7C01%7Cgdr%40microsoft.com%7C40944c682e8b4253e33408d97c459014%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637677460488643091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=x8alukuyAn6B65p%2FkKeuZ776pXt43uGB9F6xNiDY0mU%3D&amp;reserved=0
> _______________________________________________
> 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/1184.php
>

Received on 2021-09-21 10:21:15