Date: Sun, 08 Oct 2023 08:17:39 +0200
Am Samstag, dem 07.10.2023 um 18:35 +0300 schrieb Timur Doumler via Liaison:
> Right. I see.
>
> In this case you are right, P2961 as proposed for C++26 seems fully compatible with function-like-macro-ing it away in C if you so desire. The planned post-C++26 extensions are not, but we can deal with that later.
I agree, when it is understood that the extensions
are problematic.
>
> So it seems to me now that — possible post-C++26 extensions aside — the P2961 syntax is actually *more* backwards compatible than the P2935 (attribute-like) syntax. With P2961, you can adopt the same syntax in C using _Pre and _Post as the keywords and then do something along the lines of
>
> #if MY_COMPILER_SUPPORTS_CONTRACTS
> #define pre _Pre
> #else
> #define pre(...) // nothing
> #endif
>
> And then you can use standard Contract syntax even with an old compiler! On the other hand, with P2935 (attribute-like syntax), you can't do that, you'd have to wait for your compiler to know at least to ignore the colon inside [[ ... ]] which it doesn't currently do (all major compilers issue a parse error).
>
> @Martin: considering the above, do you have any more thoughts on this?
There is still the issue that "pre" and "post" will collide
with existing code.
And context sensitive keywords do not currently exist and
are also problematic. _Pre and _Post would work, but our
general goal is to then transition to lower case keywords
later (as we did already for many in C23), and I am not
sure this works for "pre" and "post".
But these issues have been pointed out by others before.
Martin
>
> Cheers,
> Timur
>
> > On 7 Oct 2023, at 17:44, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Sat, 7 Oct 2023 at 17:37, Ville Voutilainen
> > <ville.voutilainen_at_[hidden]> wrote:
> > > > Wait, not quite:, there is the syntax for return values in postconditions which is not a future extension – that's being proposed now:
> > > >
> > > > int f()
> > > > post (ret: ret >= 0);
> > > >
> > > > Is that colon in there compatible with function-like macros? Because that's not valid function call syntax at least.
> > >
> > > Of course it is, the argument list of a macro is just a token or
> > > multiple tokens. Thus:
> > >
> > > #define post(X)
> > >
> > > void f(int x, int y)
> > > post(ret: ret >= 0)
> > > {
> > > (void)x;
> > > (void)y;
> > > }
> > >
> > > https://wandbox.org/permlink/JavMNfd6kGjF9f13
> >
> > And, for what it's worth, I can make that
> >
> > post([[]]}}}][][]]]]]]}}}()();;::;;)
> >
> > which is a parentheses-balanced token sequence and thus a valid
> > invocation of that function-like macro,
> > but otherwise contains stuff that's not fathomably valid in any
> > hypothetical future version of C++, but the macro
> > slurps it just fine.
>
> _______________________________________________
> 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/1294.php
> Right. I see.
>
> In this case you are right, P2961 as proposed for C++26 seems fully compatible with function-like-macro-ing it away in C if you so desire. The planned post-C++26 extensions are not, but we can deal with that later.
I agree, when it is understood that the extensions
are problematic.
>
> So it seems to me now that — possible post-C++26 extensions aside — the P2961 syntax is actually *more* backwards compatible than the P2935 (attribute-like) syntax. With P2961, you can adopt the same syntax in C using _Pre and _Post as the keywords and then do something along the lines of
>
> #if MY_COMPILER_SUPPORTS_CONTRACTS
> #define pre _Pre
> #else
> #define pre(...) // nothing
> #endif
>
> And then you can use standard Contract syntax even with an old compiler! On the other hand, with P2935 (attribute-like syntax), you can't do that, you'd have to wait for your compiler to know at least to ignore the colon inside [[ ... ]] which it doesn't currently do (all major compilers issue a parse error).
>
> @Martin: considering the above, do you have any more thoughts on this?
There is still the issue that "pre" and "post" will collide
with existing code.
And context sensitive keywords do not currently exist and
are also problematic. _Pre and _Post would work, but our
general goal is to then transition to lower case keywords
later (as we did already for many in C23), and I am not
sure this works for "pre" and "post".
But these issues have been pointed out by others before.
Martin
>
> Cheers,
> Timur
>
> > On 7 Oct 2023, at 17:44, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Sat, 7 Oct 2023 at 17:37, Ville Voutilainen
> > <ville.voutilainen_at_[hidden]> wrote:
> > > > Wait, not quite:, there is the syntax for return values in postconditions which is not a future extension – that's being proposed now:
> > > >
> > > > int f()
> > > > post (ret: ret >= 0);
> > > >
> > > > Is that colon in there compatible with function-like macros? Because that's not valid function call syntax at least.
> > >
> > > Of course it is, the argument list of a macro is just a token or
> > > multiple tokens. Thus:
> > >
> > > #define post(X)
> > >
> > > void f(int x, int y)
> > > post(ret: ret >= 0)
> > > {
> > > (void)x;
> > > (void)y;
> > > }
> > >
> > > https://wandbox.org/permlink/JavMNfd6kGjF9f13
> >
> > And, for what it's worth, I can make that
> >
> > post([[]]}}}][][]]]]]]}}}()();;::;;)
> >
> > which is a parentheses-balanced token sequence and thus a valid
> > invocation of that function-like macro,
> > but otherwise contains stuff that's not fathomably valid in any
> > hypothetical future version of C++, but the macro
> > slurps it just fine.
>
> _______________________________________________
> 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/1294.php
Received on 2023-10-08 06:17:42