On Mon, Sep 20, 2021 at 12:48 PM Ville Voutilainen via SG21 <
sg21_at_[hidden]> wrote:

> On Mon, 20 Sept 2021 at 19:37, Ryan McDougall via SG21
> <sg21_at_[hidden]> wrote:
> >
> > Can you help me understand the concern here -- is it that C will have to
> update its grammar to recognize this syntax as not ignorable, and they
> would rather not?
>
> I can't speak for Aaron's concerns, but based on his excellent
> explanation, I have mine, which I'd wager are mighty similar to his:
>
> 1) our design goal for the syntax is that it's sufficiently
> incompatible so that older compilers don't just half-accidentally
> ignore-chomp it.
> 2) we're failing to meet that design goal, because an older C-compiler
> can ignore-chomp it and diagnose it
> as "attribute ignored". The syntax is not sufficiently different for a
> conforming older C-compiler not to mistreat
> it, and we fail to achieve the goal of a compiler syntax-checking the
> contract annotation.
> 3) in other words, the C compiler took our program, and treated it in
> a conforming way, it diagnosed a syntax
> error with a very misleading diagnostic, but was fully-conforming all the
> way.
>
> Fixing a newer C standard to require that there's additional checks
> doesn't fix this problem. The older compilers
> can still chomp+diagnose the new syntax in a manner that's conforming
> to the old rules, without performing
> the syntax-checking that we desperately want.
>


I wouldn't expect an older C compiler (or even a new C compiler where C++
has contracts and C doesn't) to diagnose my contract syntax errors.


With attribute-like syntax we get:

- old C compiler: "warning - attribute ignored".
or maybe "syntax error - that is not valid attribute syntax"

- brand new post C++23 C compiler: "warning - contract (possibly illformed)
ignored" (since C doesn't have contracts, it would ignore it, right?)
or maybe "syntax error - C does not support C++ contrats"


With some non-attribute syntax:

- old C compiler: "syntax error"

- brand new C compiler: "syntax error unexpected `contract` on line 17" (no
contracts in C)
or maybe "syntax error - C does not support C++ contracts"


Which of these possible outcomes are most concerning? Is there something
more that we are striving for than these outcomes?

For example, if C were to say "we want to support contracts, and when we do
this syntax is bad because..." I'd like to hear that.

-- 
Be seeing you,
Tony