Date: Sat, 7 Oct 2023 16:46:05 +0300
> 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.
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?
Cheers,
Timur
> 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.
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?
Cheers,
Timur
Received on 2023-10-07 13:46:09