Good point. But shouldn’t that trigger another error like “platform dependent comparison”. Seems that should be disallowed as well.
> On Oct 12, 2024, at 10:05 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sat, Oct 12, 2024 at 8:08 AM Robert Engels <reng...@ix.netcom.com> wrote: >> >> Understood - but the compiler already determines constants - determining the >> condition is a constant to avoid the current compiler error wouldn’t require >> an optimization. It seems that a constant false might also be reported as an >> error as an unreachable code block. > > We could add a special case for the literals "true" and "false". > Personally I don't think it's worth it. > > We can't add a case for constant expressions in general. On different > systems constant expressions will have different truth values. > Consider "(1 << 32) == 0". > > Ian > > >> On Oct 12, 2024, at 10:04 AM, Ian Lance Taylor <i...@golang.org> wrote: >> >> >>> On Fri, Oct 11, 2024, 9:30 PM Robert Engels <reng...@ix.netcom.com> wrote: >>> >>> FWIW, I’m not sure that I think it is the best outcome. If the expression >>> is a constant the loop can be omitted entirely - which I would hope the >>> compiler would do. And consequently the errors from the compiler should >>> reflect that - including the inverse if the expression is true. >> >> >> We want all Go compilers to agree on which programs are valid and which are >> not. That means that compiler errors must not depend on compiler >> optimizations. >> >> Ian >> >> >> >>>> On Oct 11, 2024, at 11:16 PM, Pierpaolo Bernardi <olopie...@gmail.com> >>>> wrote: >>>> >>>> On Sat, Oct 12, 2024 at 5:35 AM Cleberson Pedreira Pauluci >>>> <pauluci.cleber...@gmail.com> wrote: >>>>> >>>>> I agree with @robert. >>>>> The compiler cannot guarantee that the function will always return a >>>>> value. Even though we can see that the loop will eventually return i >>>>> value, the compiler isn't able to make this determination statically. >>>> >>>> Yes, now I get it. Thank you all for the help. >>>> >>>> Cheers >>>> >>>> -- >>>> 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/CANY8u7HOn6o557cX6Es19EX_eEi7qXBh2zECwu_jQCqhEz4atg%40mail.gmail.com. >>> >>> -- >>> 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/A9868778-43DD-467E-AAAF-D39B30EEDE16%40ix.netcom.com. -- 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/E13C08A7-950A-4299-B7D7-038EDCE3A6C3%40ix.netcom.com.