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
