The D Programming Language: cases

[terry]

	In article <24996 at cca.CCA.COM> Richard Harter writes:
	As a side point, I like the suggestion that someone made that there be
	a fallthrough statement rather than automatic fallthrough.

In a later article, Richard gives an example of his proposed syntactic change,
in response to suggestion that aggregate constructors would not be as strong as
the current language:
	
	From article <25200 at cca.CCA.COM>, Richard Harter:
	 Well, yes, one ought to be able to do that.  However it is isn't quite
	 as strong as fallthrough, where one can say

	 	switch (e) {
	 	  case foo:
	 	    some code;
	 	    fallthrough;
	 	  case baz:
	 	    some more code;
	 	  }

I think that this would be dangerous, in that it would have further reaching
effects than Richard anticipates.  Since the discussion centers around 'D',
which by context is simply "a new standard C which may not be compatable with
the current K&R standard of C so we'll call it 'D'", I believe that "upward"
compatability must be maintained if all C software is to be recompiled in D
with minimal tweaking.  While a change this drastic _could_ be worked around
with something as simple as

	#define case	fallthrough; case

this does _not_ help code generators such as YACC and LEX generate this new
code.  There are quite a number of developement tools which would have to
either be sacraficed or rewritten if D is to become the new standard.  While
this will necessary if _any_ changes are made from the current C definition,
these changes should, as a matter of course, be minimized.  The alternative
is a new language which will require ALL new tools, something I think a great
deal of people would rather avoid. 

Chris' example of aggregate constructors was:

	In article <2403 at umd5.umd.edu> Chris Torek:

	While this would work, if we assume D has aggregate constructors,
	there is a handsomer way:
 
		switch (e) {
		case [1, 2, 3, 5, 7, 13, 19, 23]: ...
		}
		/* syntax above is only for demonstration */

Given that the syntax is only for demonstration, I would suggest the following
as a better (more backward compatable) method:

		switch( e) {
		case 1,2,3,4:
		}

While apparently at conflict with the comma operator, one should realize that
the compiler expects a constant, not an expression, following a case statement,
so there would be no ambiguity in parsing.


In article <3278 at okstate.UUCP>, Gregg Wonderly has suggested that the whole
complaint centers on poor programming practices:

	You can eliminate the majority of the problems associated with `break'
	in a switch by prototyping the entire switch before filling in the code
	(you mean you are coding off the top of your head :-).

I don't think this is entirely true.  If you are a paper-programmer (one that
writes code on paper, and when it's "right", types it in), this is probably
what you'd think.  A great deal of programmers (myself included) DO program
off the tops of our heads, when the job is sufficiently simple.  In addition,
when it isn't, I use a tool called an editor ;-).  With it, I can move case
statements around to the point that I break them :-(.  This type of breakage
would not be helped by prototyping, but WOULD be caught if 'fallthrough' were
mandatory, my workaround withstanding.  A 'fallthrough' statement would save
a careless programmer (Yech! 11 characters!), but I still think it'll make
"upgrading" previous code *much* more difficult.  Besides, I never make that
kind of mistake ;-).


Gregg also complains of a style issue, particularly, leaving the braces off
of the 'if' and 'for' in the following example:

 	if (some_expression)
 		for (init; continuation_condition; repeat_code)
 			switch (val) {
 				forty jillion case's
 			}
 
complaining that it is hard to get through and find the end of the statement.
Why not use the '{' following the switch?  Indentation is part of style, too.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 }                          |
| @ Century Software          : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |