strange behavior of by-value function arguments in postcondition

[Patrick Schluter]

On Tuesday, 31 August 2021 at 12:59:33 UTC, bauss wrote:
> On Tuesday, 31 August 2021 at 12:45:29 UTC, Andrzej K. wrote:
>> On Tuesday, 31 August 2021 at 12:39:59 UTC, bauss wrote:
>>> On Tuesday, 31 August 2021 at 12:35:54 UTC, Andrzej K. wrote:
>>>>
>>>> I guess, the question here is, who are the postconditions 
>>>> for? Are they for the caller (to guarantee something that 
>>>> the caller understands)? Or are they for the callee (in 
>>>> order to automatically inject assertions into function 
>>>> body)? If it is the latter, then the current semantics are 
>>>> fine.
>>>
>>> The postconditions are for the maintainer to ensure the 
>>> function actually works as expected.
>>>
>>> If the asserts don't pass then the function has a bug.
>>>
>>> Assert statements are never for the user and always for the 
>>> maintainer.
>>
>> Yup. This explanation is compatible with what the compiler 
>> does.
>>
>> What puzzles me now is that if it is for implementer only, why 
>> should it be the part of the function signature (as opposed to 
>> the function body).
>
> I think it's just because it's better to separate asserts from 
> functionality. It makes it much more readable, especially for 
> larger functions etc.
>
> It also makes it possible to assert the return value from 
> functions with multiple return statements but in a single place.
>
In theory precondition and post condition code should be injected 
at the caller site because it is indeed part of the functions 
signature. The problem with that is that it would be quite 
inefficient as it would bloat the code significantly as it would 
copy the test code at each call site. Except for some of the 
semantic issues like OP's, putting the condition code in the 
callee is probably the better solution.