Output contract's arguements

[Artur Skawina]

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