On Sun, 26 Sept 2021 at 19:33, Gašper Ažman via Liaison
<liaison_at_[hidden]> wrote:
>
> First draft (lots of typos but i ran out of time today):
>
> https://isocpp.org/files/papers/D2461R0
>
> Looking for coauthors, use-cases, and critique.
>
> The main innovation i think it's the evaluation time split between captures and bodies of post conditions, which solves a ton of problems.

An observation: this makes it less straightforward to write the
alleged sweet-spot case of a postcondition based on a const parameter.

However, P2388 places this odd restriction on postconditions that the
parameter has to be const, even in user-facing declarations,
which we just don't do today, because we don't need to. In C++,
constness of a by-value parameter is an implementation detail,
and P2388 lifts it into the interface, and in the realm of P2388, we
have no idea how to perhaps lift that restriction.
This alternative doesn't lift such an implementation detail into the
interface, and now I can write postconditions for any parameter, and
since
that naturally raises the question of how to verify the values that
were passed in as opposed to possibly changed values, your approach
goes ahead and solves the problem.

I would encourage further work and more discussion on this.

Since this "lambda" isn't callable by other parts of the program, this
looks like something that C should be able to express, too.
It's less consistent with the current lambda proposals in C due to
those not having all the bells and whistles, but, oh well.