Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language: goto
Summary: don't remove goto
Message-ID: <2929@haddock.ISC.COM>
Date: 8 Mar 88 17:41:16 GMT
References: <12159@brl-adm.ARPA> <25350@cca.CCA.COM>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 29

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