śr., 22 wrz 2021 o 17:05 Jens Maurer <Jens.Maurer_at_[hidden]> napisał(a):

> On 22/09/2021 12.19, Andrzej Krzemienski via Liaison wrote:
> >
> >
> > śr., 22 wrz 2021 o 09:42 Ville Voutilainen via Liaison <
> liaison_at_[hidden] <mailto:liaison_at_[hidden]>> napisał(a):
> >
> > On Wed, 22 Sept 2021 at 00:02, Jens Maurer via Liaison
> > <liaison_at_[hidden] <mailto:liaison_at_[hidden]>> wrote:
> > > (Personally, I think contracts should be a first-level
> > > language feature that should not be hidden inside an
> > > attribute-looking syntax atrocity. At least in C++,
> > > the space where they are does allow for context-sensitive
> > > keywords without much hassle; cf. override and final.)
> >
> > Well, yeah.. if we were to entertain a contract declaration preceding
> > the decl-specifier,
> > so that it could do forward-lookup for the parameters, then the case
> > for an attribute-like
> > syntax would be relatively strong. If the contract declaration has to
> > appear where context-sensitive
> > keywords appear, then why not use a context-sensitive keyword?
> >
> >
> > The current contracts proposal (P2388R2 <
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2388r2.html>) 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.
>

Like

```
int f(int a, int b)
  pre: a != 0,
  pre: b != 0,
  post r: r != 0
{
  assert: a != b;
}
```

And if we were to add additional "modifiers" in the future, such as `audit`:

```
int f(int a, int b)
  pre: a != 0,
  audit pre: b != 0,
  audit post r: r != 0
{
  assert: a != b;
}
```

We will not make it for C++23 for sure. This has no implementation
experience, and it is difficult to guess (at least for me) what parsing
ambiguities this would cause.
But definitely shorter than in the current proposal.

Regards,
&rzej;