śr., 22 wrz 2021 o 17:29 Peter Brett via Liaison <liaison_at_[hidden]>
napisał(a):

> > -----Original Message-----
> > From: SG21 <sg21-bounces_at_[hidden]> On Behalf Of Jens Maurer via
> SG21
> > Sent: 22 September 2021 16:06
> > To: liaison_at_[hidden]
> > Minimum Contract Support: either Ignore or Check_and_abort
> >
> > On 22/09/2021 12.19, Andrzej Krzemienski via Liaison wrote:
> >
> > > The current contracts proposal (P2388R2
> > <https://urldefense.com/v3/__http://www.open-
> >
> std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r2.html__;!!EHscmS1ygiU1lA!RvxF
> > HnEDatbou6x94lL_6CSCp42OlaEaFUXvIXw8V0M2VJfLBbtJ1bN6rL59lA$ >) as well as
> > C++20 contracts offer(ed) three new annotations:
> > > * preconditions and postconditions that appear in function
> declarations,
> >
> > ... in a place where we have good experience with context-sensitive
> > keywords.
> >
> > > * an assertion that appears in the function body.
> > >
> > > This third kind is in the position of a regular statement inside a
> block
> > scope, so a context-sensitive keyword will not work; unless we were to
> drop
> > these assertions or treat them in a different, irregular way.
> >
> > Well, we could do
> >
> > pre: conditional-expression
> > post identifier: conditional-expression
> > assert: conditional-expression // in a block
> >
> > and the only potential conflict would be with a user-defined label
> "assert".
> >
> > (The colon should be a pretty good disambiguator for pre and post;
> > if that's not enough, we can require a logical-or-expression and/or
> > add a comma to separate contracts in declarations.)
> >
> > > Also a natural future extension of the currently proposed contracts is
> > class invariants, which would also appear as a declaration in
> class-scope,
> > so no room for context-sensitive keywords.
> >
> > With the colon, I'm not seeing a serious problem.
>
> I like this approach *a lot*. It makes sure that the contract is very
> clearly
> not an attribute, even to the casual reader, and it is more evident that
> the
> contract is an important part of the function's interface.
>
> I've had more than one person say to me, "Oh, attributes aren't important
> when
> I just want to know how to call a function and I like the '[[...]]'
> because it
> makes it easy for me to skip over them when reading." So, I think there's
> value in contracts that don't look like attributes.
>
> I wonder where I can find a compiler expert who knows how to hack this
> alternative contract syntax into a compiler's frontend...
>

Ok, so I hear now a second concern about the [[pre: x]] syntax.

The first one was that a compiler that incorrectly treats everything inside
[[...]] as an attribute can omit the parsing of the contract annotation.

The second concern here is that we send the wrong message to the
programmer: that function contracts are not important, because things in
[[]] are unimportant in terms of correctness.

Is that a fair summary?

Personally, I think that `noreturn` in declaration:

[[noreturn]] int f(int i);

Also expresses the function's contract, and is important, because it
affects what usages of the function are correct or not. Even if the
compiler "ignores" it.

Regards,
&rzej;


> Peter
>
> _______________________________________________
> 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/0768.php
>