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

[Jari-Matti Mäkelä]

Daniel Keep wrote:
> 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.

I have no experience with the 'old' concept in free functions, but I think a
class only needs to take care of its own members. If every class takes care
of their members, then all states are covered (at least according to some
OO principles). So I have initialized the old object implicitly before body
{} is executed and then accessed it in the out {} section. I have also
hidden the reference so it wont pollute the namespace. So far this has
worked fine (albeit the loss of syntax highlighting with string mixins is
not so nice - a compile time D parser would help a lot :) )