On 9/22/21 3:40 PM, Gašper Ažman via SG21 wrote:
> Personally I'm not married to the current grammar, but we do need a
> plausible alternative, and we need it soon.
>
> An alternative syntax needs to have:
> - an obvious terminator (a comma is not that, especially for assert)
> - somewhere to do the preamble (pre:, post r:, assert: )
> - not be current valid syntax.
>
> Thinking out loud here, but could braces work?
>
> auto f(auto const x, int const y) noexcept -> void
> requires integral<decltype(x)>
> pre {
> x > 0;
> y > x;
> }
> pre(axiom) {
> {x % 2 == 0};
> }
> post(audit, new) [r=return, x, y] { // seems like lambda-like
> captures fit in
> {r % x == 0};
> {r % y == 0};
> }
> {
> /* function body */
> assert {
> { x > 0 };
> };
> }
>
> That looks pretty much like the grammar for the "requires" expression
> except with runtime values. Hm.....

 From reading the discussion, this seems to solve some real concerns:

  * Per Ville's observation, it offers a solution for the concerns about
    non-const parameters.
  * It avoids the concern about the syntax looking like an attribute
    while not technically being one.

Additional benefits (in my opinion)

  * The syntax is reminiscent of function-try-blocks (though, since they
    are so rarely used, that probably has little appeal for
    non-enthusiasts).
  * It borrows from Concepts in a meaningful way. One could argue that
    pre { x > 0; }
    is the run-time equivalent of:
    requires { requires x > 0; }
    Perhaps it would be worthwhile to extend the requires clause
    directly to encapsulate Contract declarations; that would avoid the
    need for context sensitive pre and post keywords.
  * Extension points are clear and won't require new potentially context
    sensitive keywords to introduce new contract categories like axiom
    and audit.

What are the cons?

  * This is new syntax relative to what has been discussed for Contracts
    in the past; prior education is lost (this may be a good thing if
    what gets standardized deviates significantly from semantics
    associated in prior efforts).
  * Others?

With regard to function-try-blocks, I would expect that try would have
to follow any contract declarations.

void x::f(int x)
   pre { x > 0; }
try : member(x) {}
catch (...) {}

Tom.

>
> On Wed, Sep 22, 2021 at 5:48 PM Aaron Ballman via SG21
> <sg21_at_[hidden] <mailto:sg21_at_[hidden]>> wrote:
>
> On Wed, Sep 22, 2021 at 11:06 AM Jens Maurer via SG21
> <sg21_at_[hidden] <mailto: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]>
> <mailto: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]> <mailto: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
> <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] <mailto:SG21_at_[hidden]>
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg21>
> > Link to this post: http://lists.isocpp.org/sg21/2021/09/1212.php
> <http://lists.isocpp.org/sg21/2021/09/1212.php>
> _______________________________________________
> SG21 mailing list
> SG21_at_[hidden] <mailto:SG21_at_[hidden]>
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg21
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg21>
> Link to this post: http://lists.isocpp.org/sg21/2021/09/1216.php
> <http://lists.isocpp.org/sg21/2021/09/1216.php>
>
>
> _______________________________________________
> 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/1234.php