On Mon, Sep 20, 2021, 22:17 Ville Voutilainen via Liaison <
liaison_at_[hidden]> wrote:

> On Mon, 20 Sept 2021 at 23:03, Joshua Berne (BLOOMBERG/ 919 3RD A) via
> SG21 <sg21_at_[hidden]> wrote:
> > While it might be common understanding that everything between the [[]]s
> just needs to be a balanced token sequence, that is not the case in the
> actual C++ grammar or I believe in the actual C grammar. A compiler that
> accepts a contract specifier with :s as valid would be just as
> nonconforming as a C compiler as a C++ compiler doing so would be.
>
> We are not talking about a C compiler that accepts a contract
> specifier. We are talking about a practical implementation
> where the compiler ignores the attribute sequence's contents and
> diagnoses doing so. Aaron seems to be talking about
> a case where that already happens, and that approach would eat the
> attribute-specifier and diagnose it with a warning,
> and then fail to syntax-check the contract.
>
> To Martin: I don't think there's a theoretical difference here. A
> diagnostic is a diagnostic, and a C++ compiler
> could produce a warning instead of an error for a syntax error. I
> don't know whether any compiler does that for attributes.
>
> To Tony: We are considering a case where you have
>
> void f(x)
> [[pre: oink(x)]];
>
> and then if you compile that with a future C compiler with a
> C-with-contracts standard, all is well. But an old C compiler
> might just eat the attribute and not diagnose syntax errors in it, but
> it will diagnose it anyway, but maybe with a warning
> instead of an error, which is unfortunate.
>
> To Aaron: I fail to see how this is a show-stopper. Sure, you get a
> warning instead of an error. If you run a tool on the source,
> it'll tell you that your contract is nonsense. If you run a
> contracts-aware compiler on the source, it'll tell you that your
> contract
> is nonsense. Fine, you may end up in a situation where somebody in a
> team project checks in code that has nonsense
> contracts on it and thinks "well it compiled, so surely the syntax is
> ok", but it'll then be noticed later when something
> actually contracts-aware is applied on the source.
>

+1

>
> I thought I had a better argument against using context-sensitive
> keywords, that being that they need to go
> after the parameter-declaration-clause of a function declaration, but
> so do the attributes if they refer to the parameters.
> I wonder whether we have considered allowing the contract declaration
> to precede the function-declarator but
> allow it to refer to the parameters anyway. That would make the
> contract declaration more comment-like or api-documentation-like.
> _______________________________________________
> 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/0736.php
>