On Wed, Sep 22, 2021 at 11:06 AM Jens Maurer via SG21
<sg21_at_[hidden]> wrote:
>
> 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.

This sort of syntax would alleviate my personal concerns with the
proposed syntax.

In terms of whether this would be palatable to WG14, it's a bit less
clear. C has no context sensitive keywords and I have no memory of
WG14 discussions to add any, so I don't have much experience to draw
from. However, I think context sensitive keywords are a reasonable
idea worth seriously exploring as it seems at least plausible (we have
plenty of implementation and usage experience with override and final
in C++ that we can point to as prior art that's mildly C related, but
if anyone knows of a context-sensitive keyword in a C implementation,
that would strengthen the case in WG14 greatly).

~Aaron

>
> Jens
>
> _______________________________________________
> 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/1212.php