On Fri, Mar 5, 2021 at 4:36 PM Scott Pakin <scott...@pakin.org> wrote:
> I don't know if it makes any difference, but the "unreachable code" > complaint is coming from go vet, not the compiler proper. > It does. In particular, making `vet` more or less restrictive is not breaking the compatibility promise. However, OPs complaint was different. The spec currently requires a function that returns a value to end in a terminating statement <https://golang.org/ref/spec#Function_declarations>: If the function's signature declares result parameters, the function body's > statement list must end in a terminating statement. The list of terminating statements has to say about loops: A "for" statement in which: > • there are no "break" statements referring to the "for" statement, and > • the loop condition is absent. The simplest case to illustrate the issue is thus probably https://play.golang.org/p/CjKR8lV36op. It is important to clearly state, that *the compiler is thus behaving according to the spec and the compatibility promise applies*. No ifs and buts. Now. OP *is* right that it would be more consistent to treat both cases the same. However, I don't think we can reasonably do that. • We can't start to reject the program containing the `for {}` loop, as that would break the compatibility promise. • We can't say "if the loop is an endless loop, it is a terminating statement" because that would require solving the halting problem • We *could* extend the list of terminating statements to include the `for true {}` case. But this opens the question of where to stop. Shouldn't the compiler also accept `x := true; for x {}`? What about `x := 42 % 2 == 0; for x {}`? Et cetera. It's, in my opinion, unreasonable to expand the list further - in my opinion, it's already too long. • We can't drop the requirement for a function to end in a terminating statement altogether - that would open the question of what `func() int {}` does. So, I just don't see any better options than what we are doing. Keep the spec as-is, implement reasonable heuristics as warnings in vet and require the programmer to be explicit and maybe add a superfluous `return` or `panic` or whatever here and there, to make the overzealous compiler shut up. -- 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/CAEkBMfFKcQuHznwpC_hQgq58NBsyLo4vWk-jodwc-5npCOVndA%40mail.gmail.com.
