Agree completely - that’s what kind of annoys me about the unused variable
being an error. I would like a little more consistency but it is what it is.
> On Oct 12, 2024, at 10:24 AM, Peter Weinberger <p...@google.com> wrote:
>
> I think we want to limit the compiler's enthusiasms. I frequently put
> if false {...} around a piece of code i want to ignore temporarily, or
> if true {...} around an alternate implementation, and it would be
> annoying to get compiler errors, even if they were justifiable.
> There's a tradeoff with usability.
>
>> On Sat, Oct 12, 2024 at 11:09 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.
>>
>> 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/024E1FB8-CA78-4F2A-90C9-CFD5C9E2DAC0%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/BAA0F7D7-9918-4DD4-A0CF-2198769DFDE3%40ix.netcom.com.
