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_at_[hidden]> 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_at_[hidden]> 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_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
>>>
>>
>>
>> --
>> Be seeing you,
>> Tony
>>
>
>