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
