Expanding @Cerise Limón's comment into an answer, the assertion that "the first code is .. technically fine" is wrong.
The Go language specification says this:
If the function's signature declares result parameters, the function body's statement list must end in a terminating statement.
And also this:
[terminating statements include] a "for" statement in which:
- there are no "break" statements referring to the "for" statement, and
- the loop condition is absent, and
- the "for" statement does not use a range clause.
(emphasis added by me)
Examining the code in the first function we can see that these conditions of the specification are not met:
func TestMethod() int {
for i:= 0; i < 10; i++ {
return 0
}
}
The function has a result parameter (the int return value) so must end in a terminating statement, but the final statement of this function is a for statement with a condition, which is not a "terminating statement", as defined by the specification.
It may seem odd but is, in fact, technically correct.
Bonus Material
So why is the second function fine?
func TestMethod() int {
for {
return 0
}
}
In this case, the final statement in this function is a for with no condition and with no break statement referring to the for loop, satisfying the language specification definition of a terminating statement.
There is logic at work.
If a for statement with no condition contains a break, then the loop may terminate so the function needs a return statement.
If a for statement with no condition does not contain a break (and has no return statements), then the loop will not terminate (at least, not as the result of a normal execution path that requires a function return value).
Also worth noting is that there is no control flow analysis to determine whether any break statements are reachable; they only need to exist. e.g. the following will also trigger a "missing return" compilation error, even though the break is demonstrably unreachable:
func foo() int {
for {
if false {
break
}
return 0
}
// <-- error: missing return
}
exit. In more recent Delphi versions you can combine the two steps by callingexitwith a parameter that provides the desired result value:exit(x), which is exactly equivalent toreturn x.Sure in your case it would but compiler can't know that for sure, I know that may sound like perfectionism but I guess the compiler must be able to detect that case. I guess C# compiler well detects that. Again, this is not something important but it was a cool thing to know about Go. This makes a good exam question as well.something nicebut Go remains an amazing language. You know when making expression trees, similar to AST, it is not that hard to tell if something is a variable or constant. In this case the condition is based on a constant that can be easily detected by the compiler. (reference: I have been writing compilers and have written a few DSLs). However, I agree with you that sometimes it may get complicated and it is safer to not implement that functionality at all.