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.

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