> Disallowing unintended fall throughs into labeled sections of a block will prevent a class of stupid errors.
I'm stupid and I know it. Yet, it seems I haven't made this kind of error in the last ten years of Go. Maybe I'm just lucky. Or maybe this kind of error is rare. But if it's rare then a language change preventing it is questionable as the improvements would be also rare. Are there any statistics available about how many times people run into this class of bugs? The linked motivation example at https://golang.org/src/cmd/compile/internal/gc/typecheck.go?h=goto+ret#L3800 can be easily refactored to have no gotos and no labels at all. I'd say it's not a typical piece of Go code. I guess it's the original C compiler code translated mechanically to Go, isn't it? BTW: Should I send a CL? PS: Full disclosure - I think we should mostly keep the language alone. Any tiny change makes the surface of the language a tiny bit larger. But there are _tons_ of proposed language changes at the issue tracker and those tiny changes just add quickly. Also, even though not protected by the compatibility promise, almost every language change breaks an unknown number of tools people wrote in a decade. Only language changes enabling what cannot be done by other means should be considered, IMHO. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAA40n-V%3DQo9SLioE%3D36QbAbV74vh0tuN3VQh0KZCgW7f-axdwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
