Simen: >> You are of course correct. Some such analysis could still be >> performed, and the examples you give would simply leave the typestate >> in an indeterminate state.
BCS: > Having code that's "leagal unless proven guilty" doesn't sound like a good > idea to me. There are situations where it may be impossible to perform the static analysis needed by the typestate implementation (external C code that modifies some struct state or some multiprocessing situation), and in some other situations this static analysis may be theoretically possible but it becomes too much slow for a certain pathological case (so you may want to add a timeout to such static analysis), so probably in a real-world language you need some fallback mechanism, that allows you to force the compilation of the code. A typestate is a part of a type system, and generally in most type systems there are situations where it doesn't work, or it is not flexible enough. A cast() is a way to punch a hole in it and do what you need. Typestates (and generally type systems) are ways to help you avoid some classes of bugs, but they are not meant to be perfect, you need to think of them as nets able to catch only a certain percentage of the possible bugs of your code :-) You need several different strategies to catch most bugs, a single strategy is never enough. And probably if you want to add perfect implementations of DesignByContract or Typestate to a language, you have to design it from the start around such features, and this probably means your end product language will not be as flexible as D. If you add those features to an existing C-like language, you probably must accept some trade-off, as you see in the D DbC implementation. Bye, bearophile
