Output contract's arguements

[Joseph Rushton Wakeling]

On 20/09/13 20:21, monarch_dodra wrote:
> 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.

I get the concept, but I find it unattractive in practice just because it means 
you have different variables being treated differently in the out-contract 
depending on whether they are references or values.

I think that consistency of how variables are treated in the out-contract is 
probably going to turn out less problematic than a theoretically ideal situation 
where the contract addresses what the outside user can/should be able to "see".

But I accept that I may be influenced by the fact that I'm used to working in 
open-source situations where the body of a function is always available if you 
really want to look at it.  If you're looking at it purely on the basis of an 
interface or a function declaration, I can understand why your concept might 
seem preferable.

> 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.

Well, I think it's inescapable that in different circumstances you are going to 
want the out-contract to be able to access either the initial or the final value 
of a particular variable.  Preventing the programmer from doing one or the other 
seems an unnecessary restriction.

As Paolo has pointed out, it's in keeping with how contracts were originally 
defined.