why no "old" operator in function postconditions, as in Eiffel?

Daniel Keep daniel.keep.lists at gmail.com
Fri Jun 22 08:33:43 PDT 2007



Frits van Bommel wrote:
> Bruno Medeiros wrote:
>> For D to properly support 'old', D would need to clone any input used
>> as old, and that sounds as it might have some issues (not sure about
>> that though). Still, perhaps better would be the alternative presented
>> in the .learn thread where the 'out' scope would be able to access the
>> 'in' scope.
> 
> I don't think cloning is necessary. It would just need to evaluate the
> old-expression before the body is entered (i.e. at the end of the "in"
> clause) and save the result in an "invisible variable" that's accessed
> where the old-expression appears.
> Of course, it's then the programmer's responsibility to make sure that
> the result is still valid after the body has executed; if it for
> instance slices an array that's modified in the function, manual dups
> will be required.

Maybe, and I realise this might be a really ugly, hackish way to do it,
we should make "old" a special storage class.  A variable defined as
"old" in an out contract is evaluated before the function body.  This
solves this "how do we clone these things?", since the programmer can
write any initialiser that makes sense, and it clearly demarcates these
special cases.

Of course, the problem then is that the code will be *really*
counter-intuitive.

void foo()
out
{
    // gets evaluated *before* body... wtf?
    old bar = this.bar.theDupFunction();
}
body
{
    // ...
}

	-- Daniel



More information about the Digitalmars-d mailing list