C++ Logo


Advanced search

Re: [wg14/wg21 liaison] P2961R1 syntax for Contracts: viable for C?

From: Timur Doumler <cpp_at_[hidden]>
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

  #define pre _Pre
  #define pre(...) // nothing

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?


> 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