Am Freitag, dem 06.10.2023 um 14:14 -0400 schrieb Aaron Ballman:
> On Fri, Oct 6, 2023 at 2:00 PM Martin Uecker <ma.uecker_at_[hidden]> wrote:
> >
> > 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.
>
> Heh, sorry for being unclear, I didn't mean to imply it was actually a
> function-like macro under the hood. I meant `pre(operand)` where the
> syntax looks like a function call or function-like macro invocation.

Yes, I was also not clear. I think it would be fine if it
is fixed to always be like a function-like macro and
not have the [] <> prefixed versions, and it it ideally
had a longer name that we can make a true keyword later.

Martin

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