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