Output contract's arguements

[monarch_dodra]

On Friday, 20 September 2013 at 18:14:44 UTC, Joseph Rushton 
Wakeling wrote:
> On 20/09/13 18:50, monarch_dodra wrote:
>> I think it would be wrong to boot. "ref" is an indirect type, 
>> like a pointer.
>> Changes made to "it" (eg the reference'd value) *need* to be 
>> seen in the out
>> contract. I don't think it makes sense to talk about "the old 
>> value of the
>> reference". That'd be like asking for the old value of what a 
>> pointer was
>> pointing to.
>
> Yup.  But this is why I think it makes sense for a variable x 
> in the out-contract to always mean "the final value of x at the 
> end of the function". If _for reference types_ the out-contract 
> sees the changed value, that should be true for all types, 
> otherwise it's an inconsistency that is going to bite people.
>
> Then, in addition, you should be able to have an explicit 
> request (x.in, x.old ...) for the initial value (as you needed 
> in your contract).

I disagree. Isn't the entire point of "pass by value" to mean "I 
operate on a copy, so you won't see any difference to the 
argument afterwards" and ref to mean "I operate on the original 
object, so all differences I make you will see"?

I think it is wrong to think in terms of "orginal/final" to begin 
with. The "out" contract should simply see what the caller sees. 
If the function body mutates something the caller doesn't see, 
than neither should the out contract.

The notion of "old"/"new" or "in"/"out" feels strange to me. It's 
making a lot of special cases for something that should really be 
very simple to begin with.