out contract misunderstanding (was: I cannot understand problem with argument of the function)

[Artur Skawina]

On 09/19/13 20:01, Ivan Kazmenko wrote:
> On Thursday, 19 September 2013 at 07:45:44 UTC, monarch_dodra wrote:
>> On Thursday, 19 September 2013 at 06:39:09 UTC, Ivan Kazmenko wrote:
>>> On Thursday, 19 September 2013 at 01:41:15 UTC, mrd wrote:
>>>> Why argument "value" in contract isn't equal 2 ?
>>> Why should it be?  <snip>
>> I actually disagree though: How the function is implemented should have no bearing on how the output contract should be implemented. Both should get their own copy of the args. The implementation of a function should not have to create a local duplicate just because it happens to know that it has an out contract.
>>
>> This is particularly relent since (in theory), an in/out contract should appear in a function's interface, and compiled/called by client code (though that's not the case today).
> 
> That doesn't seem to be possible in every case.  For example, what if an argument is a class with copy constructor disabled?

In general, the problem is with accessing the argument at all, it
could indeed be uncopyable, but it could also be invalid /after/
the body of the function is executed. Eg

   void f(ref S s) out { assert(s.x==42); } body { free(&s); }

Anything that either invalidates or moves ownership can easily
result in invalid accesses. Variations on this could use 
pointers, classes, s/free/send/, refcounts etc (and having to
always clear every stale ref isn't a practical solution).

> I'm not claiming that the current behavior is the best one.  I just don't get a coherent picture of how it could be defined otherwise.  And the current definition seems to follow the principle of least surprise for me.

out-contracts shouldn't have access to the input args by default;
that is something that should be explicitly requested. Some syntax
sugar, for the cases when it actually is needed, could be nice, yes.

But it's not how D currently defines out contracts, so that would be
a larger change than just fixing the leak (which isn't a big problem
in itself, the implications of speccing it like that would be).

artur