Date: Sat, 7 Oct 2023 18:35:25 +0300
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.
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?
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.
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.
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?
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.
Received on 2023-10-07 15:35:29