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 wrote:
>
> On Sat, Oct 12, 2024 at 8:08 AM Robert Engels wrote:
>>
>> Understood - but the compiler already de
On Sat, Oct 12, 2024 at 8:08 AM Robert Engels 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
> e
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 wrote:
>
> I think we want to limit the compiler's enthusiasms. I frequently put
> if false
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 usab
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, Ia
On Fri, Oct 11, 2024, 9:30 PM Robert Engels 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 - inclu
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.
> On Oct 11,
On Sat, Oct 12, 2024 at 5:35 AM Cleberson Pedreira Pauluci
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 st
I have encountered the same discussion in the past at
https://groups.google.com/g/golang-nuts/c/jP_5kSTmSy4
Em sábado, 12 de outubro de 2024 às 00:35:08 UTC-3, Cleberson Pedreira
Pauluci escreveu:
> I agree with @robert.
> The compiler cannot guarantee that the function will always return a
>
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.
Compile doesn't complain about the following code. I'm no expert
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.
Compile doesn't complain about the following code. I'm no expert
On Fri, Oct 11, 2024 at 3:07 PM robert engels wrote:
>
> true is an expression, the compiler doesn’t inspect that it is a constant
> expression, thus you need the return statement
The exact rules can be seen at https://go.dev/ref/spec#Terminating_statements.
Ian
> > On Oct 11, 2024, at 4:57
true is an expression, the compiler doesn’t inspect that it is a constant
expression, thus you need the return statement
> On Oct 11, 2024, at 4:57 PM, Pierpaolo Bernardi wrote:
>
> Hello,
>
> the following code works as I expect: https://go.dev/play/p/pjKqpZyTU0d
>
> However, if I change lin
Hello,
the following code works as I expect: https://go.dev/play/p/pjKqpZyTU0d
However, if I change line 15 from
for i := 0; ; i++ {
to
for i := 0; true; i++ {
it does not compile. In my understanding the two should be equivalent,
but they are not. Maybe I'm missing a simple explanation?
--
14 matches
Mail list logo
