Output contract's arguements

[Joseph Rushton Wakeling]

On 20/09/13 18:37, H. S. Teoh wrote:
> True. I agree that redefining plain "x" to mean "initial value of x"
> would be difficult to implement for ref arguments, and will also break
> existing code to boot. Having access to x.old is the best solution where
> possible (I'm thinking, for the sake of implementational simplicity,
> that we can restrict x.old to only work for parameters passed by value,
> since D doesn't have a generic way of cloning a reference argument).

Agree.

> No, but the current notation is ambiguous and misleading. I agree that
> x.in and x.out (or some such notation) is better.

Yes, I can go with that.  There could be a deprecation path for x => x.out if 
that's desirable, although there's precedent (as Paolo has pointed out) for 
using just x.

> I would rather say that it's illegal to refer to plain 'x' in an
> out-contract because it's ambiguous. It should always refer to either
> x.in or x.out. (Of course, we can silently still support the current
> syntax in order to preserve backward compatibility, but I'd really
> prefer it to be deprecated.)

Sure.

> This issue is fixed if we make x.in and x.out mandatory.

Agree, and I was never arguing against that.

> I'd say this is a good argument for making x.in and x.out mandatory
> syntax. Then it becomes clear and readable:
>
> 	void foo(int *x)
> 	 in { assert(*x.in >= 0.0; }
> 	out { assert(*x.out >= 0.0; }
> 	body { ... }
>
> And for moving non-contract asserts (i.e. those that check
> implementation sanity rather than make any guarantees of interest to the
> caller) into the function body rather than putting them in the
> out-contract.

In this case, yes, you can reliably handle it with in/out syntax.  It becomes 
problematic if x is a more complex data type, e.g. a class with many 
reference-type members (arrays, other classes, ...).  As there's no way to 
reliably do a deep copy of such an entity (and of course you might have entities 
such as input ranges where you really can't preserve the state), there are 
always going to be function inputs where you can't readily access x.in in the 
out-contract.