jlg@lambda.UUCP (Jim Giles) (03/10/90)
The problem with fall-through is not what everybody thinks it is. Many
of the C programmers on the net are even claiming that it's a virtue of
the language. The _real_ problem with fall-through on cases is two-fold:
1) The most common case is that you don't want to fall-through. For this
reason, if for no other, the default behaviour of the case construct
should be NOT to fall-through.
2) Fall-through is just a single degenerate case of the more general idea
of 'more than one of the following'. Why limit the language to just
this single subcase?
An example of an improved select/case construct is below:
select test_val of
case First_possibility:
do_something;
reselect Common_exit;
case Second_possibility:
...
case Last_possibility:
do_something_else;
reselect Common_exit;
case Common_exit:
do_common_processing;
end select
Here there is no automatic fall-through. Without the 'reselect', each
case would terminate at the next 'case' statement. The 'reselect'
behaves as a fall-through, but to an arbitrary following case (in the
example: the 'Common_exit'). This, more general, approach includes
the C fall-through behaviour as a subset. It is cleaner in that it
requires the fall-through to be explicitly stated.
Further syntactic sugar would be the specification of multiple conditions
on the same case (as many languages already have). This eliminates all
excuses that C supporters have for the way C does select/case.
J. Giles