A third point would be that if we mark the boundary functions (as proposed) then such marking only has to be done a few times (in the contract library itself).  If we mark each individual boundary function call then this needs to be done many times (at each call site).  Furthermore, your proposed syntax for marking is not feasible as pre and post are not claimable as keywords.

I find this intrinsic vs extrinsic classification point as highly subjective, and its difficult to give it any weight in the pros vs cons analysis.

As for the idea of exposing the return value through std::expression - as proposed, std::expression and epilogue functions are currently two completely orthogonal language features.  I'm not even sure what you're proposing exactly.

On Wed, Aug 7, 2019 at 10:32 AM Tony V E <tvaneerd@gmail.com> wrote:
The radius of a circle is intrinsic - it defines the circle. 
The position of a circle is often treated as a property of the circle, but is actually a property of the circle *in relation to* its surroundings. It should be considered extrinsic to the circle. 
(should two circles of the same size be considered equal, etc...)

Prologue and epilogue seems to be a relationship between the function and where it is called, not a property of the function itself. ‎Most functions don't have restrictions about where they are called (like 'can only be called directly from main' or 'only as part of static initialization'). We do have constexpr functions, but they have conditions intrinsic to the function that are allowed or not (although we are removing most of those limitations). Whereas constinit is a property of the call site not the function.

Intrinsic vs extrinsic is a standard question I ask about most design issues. 

I agree 'access to return value'  would be a differentiation, but that might be better captured by std::expression instead of epilogue. Or be intrinsic to some pre: cond() syntax - as return value is intrinsic to the callsite, not the cond(). 

Sent from my BlackBerry portable Babbage Device
From: Andrew Tomazos
Sent: Tuesday, August 6, 2019 8:14 PM
To: Tony V E
Cc: sotrdg sotrdg via Std-Proposals
Subject: Re: [std-proposals] Proposal of Contract Primitives (DRAFT 1)



On Wed, Aug 7, 2019 at 2:29 AM Tony V E <tvaneerd@gmail.com> wrote:


Why is prolouge/epilogue a property of the function, instead of where it is called from?

ie

    prolouge precond(...expr...);
    epilogue postcond(...expr...);

    f() precond(x > 0) postcond(z < 0);

vs

    void cond(...expr...);

    f() pre: cond(x > 0), post: cond(z < 0);

Is prologue/epilogue an *intrinsic* property of the function it is tagged to, or an *extrinsic* property of where it is to be used?
I think it is extrinsic.
 
I'm not sure I know the difference between an intrinsic property and an extrinsic property, but two points:

1. Given your function cond I can write two one-line functions:

    prologue void inline precond(bool condition) { cond(condition); }
    epilogue void inline postcond(bool condition) { cond(condition); }

To get the same functionality.

The reverse is not so.  Given two distinct functions precond and postcond, I can not write a single cond function that wraps them.

You may want to do different things in a precond and postcond function (including, say, putting in the error message "precondition violation" or "postcondition violation" respectively)

2. We may want to provide distinct functionality to prologue functions and epilogue functions later.  For example, I could imagine a future extension that allows access to the return value within epilogue function definitions but not within prologue function definitions.

On Tue, Aug 6, 2019 at 4:19 AM Andrew Tomazos via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Please find attached DRAFT 1 of:

    Proposal of Contract Primitives

Feedback appreciated.
    -Andrew.

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Be seeing you,
Tony