The fact that "for{}" is a terminating statement and "for true {}" is not,
parallels the fact that "return" is a terminating statement and "if true {
return }" is not.
On Friday, March 5, 2021 at 4:25:17 PM UTC-8 Ian Lance Taylor wrote:
> On Fri, Mar 5, 2021 at 4:11 PM 'Axel Wagner' via golang-
On Fri, Mar 5, 2021 at 4:11 PM 'Axel Wagner' via golang-nuts
wrote:
>
> 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
> prov
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 onl
On Fri, Mar 5, 2021 at 4:36 PM Scott Pakin 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,
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 oppo
* Brian Candler [210305 10:21]:
> There is a flip side to that: if you add the return statements, then
> ForLoop1() gives an error due to unreachable code!
> https://play.golang.org/p/0bajnJWTz7U
>
> So you can't win either way. I think this implies that if the behaviour
> were changed now, it
On Friday, March 5, 2021 at 8:20:36 AM UTC-7 Brian Candler wrote:
> There is a flip side to that: if you add the return statements, then
> ForLoop1() gives an error due to unreachable code!
> https://play.golang.org/p/0bajnJWTz7U
>
> So you can't win either way. I think this implies that if the
There is a flip side to that: if you add the return statements, then
ForLoop1() gives an error due to unreachable code!
https://play.golang.org/p/0bajnJWTz7U
So you can't win either way. I think this implies that if the behaviour
were changed now, it would break the go compatibility promise.
O
Another way to look at it.
The Go Programming Language Specification
https://golang.org/ref/spec
For statements
For statements with for clause
ForClause = [ InitStmt ] ";" [ Condition ] ";" [ PostStmt ] .
Any element of the ForClause may be empty but the semicolons are required
unless there i
