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?

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
>
>
>
>
>
>
>
>
>