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.

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.