> -----Original Message-----
> From: SG21 <sg21-bounces_at_lists.isocpp.org> On Behalf Of Jens Maurer via SG21
> Sent: 22 September 2021 16:06
> To: liaison_at_[hidden]rg
> 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...

                     Peter