On Fri, Oct 6, 2023 at 12:56 PM Timur Doumler <cpp_at_[hidden]> wrote:
>
> OK, thanks, I understand that argument now.
>
> I am not sure though if it makes much sense to design our syntax around that, given that we *already* know we can't (and don't want to) achieve this kind of seamless backwards-compatibility in C++, and by extension in any code shared between C and C++, so only codebases in pure C would benefit from such a possibility. And you won't get backwards-compatibility with older compilers, only with newer compilers in "old standard" mode, because every existing compiler I'm aware of rejects the colon between [[...]] as a syntax error today.
>
> However, my understanding is that with either of the syntax proposals, we would be able to achieve backwards-compability with older compilers via wrapping the whole feature in macros, in exactly the same way we do for other new features that add new syntax.
>
> I am really interested whether anyone here has a preference for one syntax and against the other for any other reason that does *not* have to do with ignorability?

I strongly prefer the syntax that looks like a function-like macro
over the syntax that looks like an attribute. I think it eases
portability, especially when compiling newer source code with an older
implementation. I don't think we should be making the user scan for
whether there's one colon or two colons to know what language feature
they're using. I think constructs like lambdas can already look quite
noisy with their balanced delimiters and this introduces another
instance of that. Also, it helps this confusion by making it more
visually distinct:

void func(int i) <Which comes first: type attributes or contracts?>;

While users still need to know which order to put things in because we
don't allow interleaving there, at least they're not trying to
remember how to order two things both using [[]] syntax.

~Aaron

>
> Cheers,
> Timur
>
> > On 6 Oct 2023, at 19:35, Jens Maurer <jens.maurer_at_[hidden]> wrote:
> >
> > 
> >
> >> 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?
> >
> > 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.)
> >
> > Jens
> >
>