Communicating between in and out contracts

[Rainer Deyke]

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.  Complex
expressions are just simple expressions applied recursively.  The
compiler already knows how to deal with complex expressions.

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.


-- 
Rainer Deyke - rainerd at eldwood.com