On Fri, 6 Oct 2023 at 08:31, Martin Uecker <ma.uecker_at_[hidden]> wrote:
> To be honest, I think it is a mistake also for C++. I believe
> that even for C++ people will end up trying to introduce this into
> existing code and then are forced to make it ignorable by wrapping it
> into #ifdef or macros. The end result would neither be nice
> nor ignorable.

Sure, but that's no different from conditionally adopting any other
new language facility that
the older implementations don't recognize. Which for C++ is almost
every new language facility.
We have standardized feature-detection macros, even, to help with
preprocessor-based conditional
migration.

> > It wouldn't cause me loss of sleep if C compilers were allowed to
> > completely ignore a contract annotation.
> > Fixing syntax errors when using a compiler that doesn't ignore them is
> > compatible with compilers that would
> > ignore the annotations.
>
> Right. And especially in a context where headers are shared, the
> scenario that for some transition time (probably decades) the code
> needs be processed also by compilers not supporting contracts seems
> very likely.
>
> For C I think it would be important to have a syntax that is ignorable.

Just to make sure I understand.. in effect, to make the feature
optional? So as to not hoist
its burden on implementations that don't want it?

> A syntax as proposed here (it seems, correct me if I am wrong) such
> as:
>
> void f(int x)
> pre <audit> (x > 0);
>
> would be a pretty bad choice for C.

The <audit> part is at this point hypothetical. I'm curious why you
think that's a bad choice.
If I understand things correctly, it's novel for C to have function
parameters be in scope
after leaving a function declarator and before a function definition
begins. In C++, that hasn't
been novel for ages, with trailing return types,
noexcept-specifications, and constraints all
using function parameters.