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 - rain...@eldwood.com