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.
