karl@haddock.ISC.COM (Karl Heuer) (03/09/88)
In article <25350@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >Yes, there are rare occasions where a goto lets you build by hand a construct >that is not available in the language. Most of these instances reflect >deficiencies in the language. There are only three reasons for using a goto. Firstly, to implement a control structure not directly available in the language in question. This "deficiency" is not necessarily bad; I've used goto to emulate coroutines, but I probably wouldn't want to see coroutines added to the language. If you remove goto but then add every other possible flow construct just to avoid the desire for a goto, you end up with BLISS. Let's not do that. Secondly, error handling, which could be considered a special case of the first reason in that it emulates an exception construct of some type. This includes not only cleanup-and-return but also retry-operation; sometimes a simple backward goto is clearer than a while. Thirdly, you can use a goto if you really, really want to, a whole lot. :-) (I use this as my universal escape clause.) >The question I was raising was whether the rare instances where a goto >is actually useful warrant retaining it in the language. I think so. When you do need it, it's a pain to emulate. Also, it would be nice if D source could be automatically generated from C source. Retaining the goto makes this easier. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
g-rh@cca.CCA.COM (Richard Harter) (03/09/88)
In article <2929@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
[Three reasons for retaining goto's. Plus a compatibility argument.]
I guess I have to give up. The consensus seems to be that goto's should
be retained, despite their reputation. "The best programmers use goto's,
but only in private, you know." Can we settle for lint giving you a warning
if you use a goto? :-)
--
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Richard Harter, SMDS Inc.