On Wed, Sep 22, 2021, 21:41 Gašper Ažman via Liaison <
liaison_at_[hidden]> 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?
>

The previous suggestions about

pre: :
post :
assert:

can only conflict with labels.
A quick scan of the vcpkg repository (649389 files) does not show any
conflict
And that syntax seems reasonable to me.
It's about the same as the current syntax with no [[ ]], if I understand
correctly.



> 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.....
>
> On Wed, Sep 22, 2021 at 5:48 PM Aaron Ballman via SG21 <
> sg21_at_[hidden]> wrote:
>
>> 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
>> _______________________________________________
>> 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/1216.php
>>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/09/0784.php
>