Am Freitag, dem 06.10.2023 um 13:57 -0400 schrieb Aaron Ballman via Liaison:
> 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.


I think function-like macros were not proposed. But I would also
prefer this.

Martin

>
> ~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
> > >
> >
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/10/1274.php