Communicating between in and out contracts

[Andrei Alexandrescu]

Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> It is if x is an _arbitrarily complex_ expression, and if that
>> expression is part of a _complex control flow_. The language definition
>> would have to decide exactly where complex is too complex in the
>> expression or the control flow. That complicates the language. Also, by
>> necessity the feature will be limited and will not give people enough
>> freedom. It's lose-lose.
> 
> The complexity of the expression is irrelevant, since the expression is
> simply moved to the beginning of the function as a unit.

The expression may mutate stuff.

> Complex
> expressions are just simple expressions applied recursively.  The
> compiler already knows how to deal with complex expressions.

Heh, that's not what I was worried about. It's mutation and dependencies.

> Control flow is also irrelevant because it is simply ignored.  The AST
> transformation sees this:
>   blah blah old(x) blah old(y) blah
> ..and turns it into this:
>   blah blah cached_value_0 blah cached_value_1 blah
> 
> Yes, this means that the expressions 'x' and 'y' cannot use any local
> variables from the postcondition block.  If you want to cache values in
> the precondition block for use in the postcondition block, you can't
> wait until you reach the postcondition block before deciding what to
> cache.  This limitation exists whether the caching is manual or automated.
> 
> If you insist on arguing about this, please direct your complaints to
> the Eiffel community and tell *them* how the language feature they've
> been using for years is broken.  If there really is something wrong with
> Eiffel-style 'old' expressions, I'm sure the Eiffel community would know
> about it.

If you know about Eiffel's old, I'd appreciate if you explained how it 
works. I am arguing exactly because I don't know. My understanding is 
that neither of us currently knows how it works, so I don't think it's 
ok to refer me to Eiffel.


Andrei