I do not like the syntax for std::expression. It violates the principle of
least astonishment - anyone who sees (LHS) = (RHS) expects RHS to be
evaluated. At the very least that assignment operator would need to be
swapped out for something that does not apply evaluation, but I'd still
prefer to step away from the DSL and have something along the lines of a
std::invoke_later(func, params...) instead.

If it is equivalent to the lambda as you suggest, what happens when it goes
out of scope? Sure, those who are used to writing this in lambda form will
know to use captures, but here that is not catered for. That's about all I
have for the std::expression type as a standalone entity.

For the prologue and epilogue, the original ensures and expects syntax made
sense. My problem with the proposal was the inflexibility and somewhat
bizarre categorisation, rather than something simple like an unsigned
integer debug level which can be set as a compilation flag (such that 0
only evaluates debug level 0, 1 evaluates 0 and 1, 2 evaluates 2,1 and 0,
and -1 evaluates none of them), a binary mask, or a keyword lookup. The
expects and ensures could also have been easily identified during
optimisation steps to match up assurances with expectations. I think this
is less clear. It is also unclear how the prologue can know the names of
the input variables, given that they're defined afterwards in the standard
function definition.

On Tue, 6 Aug 2019, 09:19 Andrew Tomazos via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> Please find attached DRAFT 1 of:
>
> Proposal of Contract Primitives
>
> Feedback appreciated.
> -Andrew.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>