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.

Reply via email to