On Friday, 5 March 2021 at 15:35:48 UTC Scott Pakin wrote:
>
> The Go developers might want to comment on this, but my interpretation of
> the Go compatibility promise is that working programs won't break, not that
> programs that fail to compile will suddenly compile.
>
I was thinking the opposite, that code which previously compiled then fails
to compile. Say someone has written this:
func ForLoop2() int {
for i := 0; true; i++ {
if i%123 == 0 {
return 456
}
}
return 0
}
They were forced to include the "return 0" because although it's not
needed, the compiler refuses to compile without it. All works.
Now let's say the behaviour is changed so that the "true" condition is
understood by the compiler to mean an infinite loop, and the subsequent
code is known to unreachable. I was thinking that the code will now refuse
to compile, because go will reject the program (it will says the "return 0"
is unreachable code).
But then as you pointed out:
>
> I don't know if it makes any difference, but the "unreachable code"
> complaint is coming from go vet, not the compiler proper.
>
Ah yes - it does make a difference.
Tested with command-line go (instead of playground):
$ go run f1.go
# command-line-arguments
./f1.go:19:1: missing return at end of function
$ go run f2.go
$ go vet f2.go
# command-line-arguments
./f2.go:10:2: unreachable code
So including the "return 0" doesn't prevent it from compiling, it only
causes "go vet" to whinge.
--
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/e475d8c6-6011-4ee8-ad31-19b425b3c6f1n%40googlegroups.com.
