Output contract's arguements

[PauloPinto]

On Thursday, 19 September 2013 at 12:04:34 UTC, Artur Skawina 
wrote:
> On 09/19/13 13:11, Peter Alexander wrote:
>> On Thursday, 19 September 2013 at 11:07:07 UTC, Artur Skawina 
>> wrote:
>>> On 09/19/13 12:58, Peter Alexander wrote:
>>>> On Thursday, 19 September 2013 at 10:44:32 UTC, 
>>>> monarch_dodra wrote:
>>>>> On Thursday, 19 September 2013 at 10:38:37 UTC, Joseph 
>>>>> Rushton Wakeling wrote:
>>>>>> On 18/09/13 14:11, monarch_dodra wrote:
>>>>>>> IMO, this is wrong. When calling a function with an out 
>>>>>>> contract, the arguments
>>>>>>> should *also* be passed to the out contract directly. 
>>>>>>> "out" should not be
>>>>>>> expected to run on the body's "sloppy seconds".
>>>>>>
>>>>>> I'm not sure I understand your objection here.  As I 
>>>>>> understood it the whole point of an "out" contract was to 
>>>>>> check the state of everything _after the function has 
>>>>>> exited_.
>>>>>
>>>>> Exactly.
>>>>>
>>>>> If the function has already exited, then why is the state 
>>>>> of he arguments modified? I though pass by value meant that 
>>>>> the function operated on its own copy?
>>>>
>>>> What exactly would you like this to do? v only exists inside 
>>>> the body of the function. There is no v after the function 
>>>> exits. If you check v in the output contract then you are 
>>>> checking the final value of v.
>>>
>>> That "final value of v" is not part of any contract, it's 
>>> just a private
>>> local.
>> 
>> I repeat my question then: what would you want this to do? As 
>> you say, v is a local copy, it cannot be part of a contract -- 
>> it cannot affect anything the client code sees.
>
> A contract only describes the /external/ interface (inputs, 
> outputs
> and visible state).
> It makes no sense for it to depend on any local private 
> variable of a
> method; 'assert's in the function body can be used to verify the
> implementation.
> Leaking the internal state into the contracts has consequences, 
> such as
> making it much harder to use the same 
> executable/library/archive for both
> debug and contract-less builds (well, w/o duplicating all the 
> code,
> instead of reusing the bodies). Being able to easily check the 
> contracts
> at the exe<>dll boundary is important; if this requires using a 
> different
> library binary or causes massive bloat then this feature simply 
> won't be
> used much...
>
> artur


Sorry but this is not like that.

Contracts also make use of invariants for the internal state of 
the object.

This is exactly what out conditions are suppose to validate.

- The internal invariants are still valid on function's exit
- The returned value and parameters passed by reference have the 
expected values

At least if D is supposed to follow what Design by Contract means 
in languages that already provide it, specially Eiffel which is 
the language that gave birth to these ideas.

--
Paulo