On Sun, 8 Oct 2023 at 16:41, Martin Uecker <ma.uecker_at_[hidden]> wrote:
> > To me, this compromise sounds doable, consistent with what we've done before for other features shared between C and C++, and still better than using [[ ... ]] which apparently in C has the
> > notion of "this is token-ignorable". At least for newer compilers that know about Contracts, token-ignoring Contracts is not something that I would want to allow or encourage. Attributes in
> > C are all either for enabling/disabling warnings or for giving optimisation hints to the backend. Contracts are not like that at all. They are a core language feature and there is nothing
> > "optional" about them – in the sense that an implementation shouldn't be allowed to just not implement them and still be conforming.
> >
> > Anyway, I hope this makes sense, but if I'm missing something please let me know!
>
> I still like to comment on this last point and why I am
> not convinced by it.
>
> First, whether a new implementation is allowed to ignore
> them or not, is a matter of standardization and not of
> syntax: If the standard says it can be ignored it can
> be ignored and it says it cannot ignored, then it cannot
> be ignored by a conforming implementation.
>
> Second, attributes are ideally suited and would solve all
> the technical issues related to backwards compatibility
> we discussed here in a nice way. The would also have
> no risk, as we can always invent new syntax later.
> In contrast, introducing new syntax now has a huge risk
> and opportunity cost.
>
> Finally, I think from a perspective of semantics, attributes
> are also an excellent fit: Contracts are annotations that
> - when removed from a correct program - should not change its
> semantics. For me, this makes them seem more similar to
> other annotations (as expressed by attributes) than to other
> language constracts. For me, the use of attributes for all
> such annotations would make a lot of sense. This would be
> easy to explain and teach and work with.


For what it's worth, the remarks about contract ignorability don't
convince me either. I can live with it just fine
if C++ compilers are not allowed to ignore contract annotations, but I
don't see a theoretical or a practical
need to impose the same requirement on C compilers. We have four C++
compilers to worry about,
and all of them seem capable of strictly implementing the same rules
in this area, that they won't ignore
contract annotations and will diagnose syntax errors in them.

There's many more C compilers, and some of them are.. ..for the lack
of a better word, smaller-scale.
Some of them might be geared for use cases and audiences where
implementing contracts is a significant
burden without much added value. So allowing such implementations to
ignore contract annotations
would make their implementers' lives easier.

And, again, for manyeth time: the sky will not fall if someone
develops a library that I really want to use,
but compiles it only ever with a C compiler that ignores contract
annotations. Once I compile it with an implementation
that syntax-checks contract annotations, I can report back bugs, if any.

That scenario is rather unlikely, and it's quite likely that code that
I want to use with contract annotation syntax
checks on will already have been compiled with a compiler that doesn't
ignore contract annotations.

In other words, insisting that C compilers shouldn't be allowed to
ignore contract annotations because C++ compilers aren't
has
A) seemingly remotely plausible downsides for contract users
B) and therefore remotely plausible upsides for contract users
C) some highly plausible downsides for implementers of simplistic C compilers
D) and likely no upsides for those implementers

The combination of that is that I don't see the point of insisting on
it. The only people who will notice this in practice
are the compiler implementers who have a choice between suffering a
burden of implementing something they see
no use for, and being non-conforming. The users mentioned in A/B will
not see this problem in practice, or in the
rare case where they do, fixing it should be fairly simple and quick
and is 100% compatible with a C compiler
that ignores contract annotations.

And, after all, a 100% conforming C++ implementation could say "yes, I
implement C++ contracts, but the only semantic
available is 'ignore', so I'll never perform a run-time check of a
contract nor will I invoke a violation handler". All in all,
it doesn't add much that such an implementation will syntax-check a
contract annotation, when using such an implementation
doesn't otherwise result in the contract annotations having any
effect, other than language-lawyering ones such as ODR-using
the entities named in the annotations.