On Sat, 7 Oct 2023 at 16:46, Timur Doumler <cpp_at_[hidden]> wrote:
>
>
>
> > On 7 Oct 2023, at 16:38, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> > For that kind of types, you'll need to do something different from
> > just a plain copy in the 'capture', so just do the same thing for the
> > work-around.
>
> Oh, I thought this was not about the capture, but about naming the return value in the postcondition. If this is a language feature, it will just be an automatically-generated const reference to the actual return value. You don't need to name the return value in the body of the function. You can't do that with a macro.

Right. In C, you can always wrap a function body, get the result of
it, check it, and return it from a wrapping-function (although just
macroing a 'pre' won't suffice for that). In C++, you can't do that,
that would break either identity or elision, in some cases.

> But yes, I get your point, you could still have a syntax that looks like a function-type macro so while you can't replicate the behaviour without the new language feature, you can at least macro it out and avoid syntax errors, without the need to surround the contracts with #ifdefs. That's the idea here, right?

Right. But I don't think that's worth anything for C++ programmers.
It's doubtful we'd want to suggest that they polyfill a language
facility
with lowercase macros; for all intents and purposes, it's better just
to tell them to #ifdef things out with the help of feature-detection
macros, and macro the whole contract annotation with a "normal"
uppercase macro. So, while being macro-friendly to such polyfills
may be better for our WG14 friends here, I can easily see some WG21
members balking at the idea with a "that's not a technique
that we want to encourage".