C++ Logo


Advanced search

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

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Wed, 22 Sep 2021 17:05:42 +0200
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

> * 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.


Received on 2021-09-22 10:05:51