Goto isn't used often in Go because it has to be invoked on its own line inside a conditional statement block, which often can perform the same decision if you think it through, as well as moving shared elements into functions that share the receiver or have common interfaces, outside of the function. Goto based on a prior statement setting an error would be far more useful, which gets back to my conditional return idea (and then maybe this could be a pattern applied to these scope jumping functions in general, that they can be aborted by a false boolean. Goto is already bound within function scope anyway, so making it more useful couldn't do any real harm, and conditional branching would be the one.
It's kinda ironic to me that such a simple idea is so infrequent in high level languages yet everywhere from the assembler macro preprocessor on down. Break, continue, goto, return, all of them would become amazing with conditional execution. For me, the novel if and for syntax was the biggest stand-out thing I noticed about Go, at the beginning. I had already got familiar with closures , and it took some time to absorb exactly what interfaces are about. They are amazing but the various cool features of if's pre-condition statement and the condition-only for (removing the need for the semicolons especially), these are a break outside of the very tired conventions of for if while wend foreach, etc etc, and let you structure the logic flow more intuitively and visually. Switches look nice and read well, but the keyword and block boundary raise the cost of casual use. On Tuesday, 25 September 2018 04:15:02 UTC+2, Robert Engels wrote: > > Pretty sure that is what I said... duplicate the work in every case is > silly, thus the goto... if no work, no need for goto > > > On Sep 24, 2018, at 9:10 PM, Dan Kortschak <dan.ko...@adelaide.edu.au > <javascript:>> wrote: > > > > Rule: All rules are bad (including this one). > > > > goto is useful when there is a need to do some elaborate clean up (or > > other work) at the postamble of a function, but in many cases it > > becomes clearer to have the work done at the location (say in the > > switch in the example in this thread). Use of judgement is worthwhile > > as to whether this is true for any particular situation. > > > >> On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: > >> You should always return from the place of return, or goto > >> return_label, when a result/error needs to be formatted. > >> > >> See the Knuth paper I posted a while ago on using goto... > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
