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-nuts
> <golan...@googlegroups.com> 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 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.
>
> Yes, in general we don't want compilers to accept or reject programs
> based on heuristics. That would mean that different compilers would
> accept or reject different programs. We want to avoid that as much as
> is feasible. We want all the compilers to implement the same
> language.
>
> Ian
>
--
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/0f91b03e-59d6-4d23-aca8-cdcdf7b41067n%40googlegroups.com.
