Hi Timur,

Am Freitag, dem 06.10.2023 um 20:14 +0300 schrieb Timur Doumler:
> Hi Martin,
>
> Since backwards-compatibility with older compilers isn't achievable in this case (every compiler I know of will reject the colon in the attribute-like P2935 syntax as a syntax error), and the best thing you can get is backwards-compatibility with older C standards on a new compiler that already knows about Contracts and implements the "colon tweak" that was mentioned earlier, do you still think that this limited kind of backwards-compatibility is valuable enough to design the syntax around that?

yes, I think so. Considering the time frame until
this feature lands and will be fully supported, I
would expect there that there is a useful period
where compilers could still add the tweak.

Also consider that older versions are often still
maintained. GCC 11, 12, and 13 all get updates even
though GCC 14 is in development and I am sure other
people even maintain older versions of GCC on their
own. Those older version will certainly not get
a new feature such as contracts but could potentially
be tweaked to accept the colon.


So if I had to choose between both proposals now,
I would pick the attribute-like syntax, because there
is still a better chance that we can avoid that
users have to write

int foo(int x)
  CONTRACT_PRE( x > 0 );

later.

But if WG21 picks the other one, the world will also
not going to end for me.

Martin


>
> Cheers,
> Timur
>
> > On 6 Oct 2023, at 20:06, Martin Uecker <ma.uecker_at_[hidden]> wrote:
> >
> > Am Freitag, dem 06.10.2023 um 18:35 +0200 schrieb Jens Maurer via Liaison:
> > >
> > > > On 06/10/2023 18.32, Timur Doumler wrote:
> > > >
> > > >
> > > > > On 6 Oct 2023, at 19:28, Jens Maurer <jens.maurer_at_[hidden]> wrote:
> > > > > > If that is indeed the case, then the attribute-like syntax for Contracts would not be ignorable in C, either.
> > > > >
> > > > > Right, but the argument is that implementations can add the small extension
> > > > > to parse-ignore ":" in that spot right now, and then be future-proof for
> > > > > ignoring future attribute-like contracts.
> > > >
> > > > Right. Yes, I can follow that argument. But that begs the question: what is so special or different about Contracts that you want this feature in particular to be backwards-compatibly-ignorable by older compilers, considering that we don't do that for any other new language feature where we add new syntax to the language?
> >
> > In general, of course, we would *all* language features to be
> > backwards compatible. The reason is that all new features have
> > cost in terms of breaking compatibility.
> >
> > But for many features this is obviously not possible. For
> > contracts it seems this would be possible, exactly because
> > you are not supposed to rely on specific failure semantics.
> >
> > >
> > > The argument, as far as I understand, is that contracts in particular are well
> > > suited to be retrofitted on existing code bases that need to be compatible
> > > with older compilers / language versions.
> > >
> > > For any other new language feature, you can just choose to ignore it for your
> > > meant-to-be-compatible code base. But contracts are so valuable to find
> > > bugs in existing software, so you want them everywhere ASAP.
> > >
> > > (I'm just repeating an argument I think I heard. This is not my opinion.)
> >
> > Yes.
> >
> > And it seems clear to me that people will introduce this feature
> > into existing code as soon as it is available in some compilers
> > using preprocessor conditionals and I expect that this will be
> > the most common use case.
> >
> > So why make this hard? We should optimize for the most common
> > use case. Everything else just hurts our users unnecessarily.
> >
> > This could be attribute syntax but also a macro-based syntax.
> >
> >
> >
> > Martin
> >
> >
> >
> >
> >
> >
> >
> >
> >
>