FWIW, one option I didn't mention, but which deserves a mention: We could replace "all other statements are not terminating" with "an implementation is allowed to treat other statements as terminating, if it can prove it" (or similar). This wouldn't break the compatibility promise, as it would only start accepting programs that are currently rejected. However, the job of the spec is to clearly say which programs are valid and which are not. There are *some* cases where the spec allows an implementation to chose behaviors - but I don't think any of them would make the validity of go programs so blatantly dependent on what heuristics a compiler author might consider reasonable or not. They are mostly about performance and future-proofing. So we'd likely pay a pretty hefty price in terms of portability of code between compilers. We *could* still do it, but we still need to ask ourselves if it's really worth it. After all, again, the worst case is having to add an extra `return` here and there.
There's also, FWIW, another argument that could be made. Which is that it also should be obvious to a human reading the code that the loop is an endless loop. Requiring the condition to actually be empty is easily scannable. And it might not be such a bad thing, to force people to write more obvious code. On Sat, Mar 6, 2021 at 12:47 AM Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > 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/CAEkBMfEK9JzKJv427pakQZEveF2jPQ4TDeGEB0EU055J3XV9Bw%40mail.gmail.com.
