for mystery
279 views
Skip to first unread message
Pierpaolo Bernardi
Oct 11, 2024, 5:58:42 PM10/11/24
to golang-nuts
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?
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?
robert engels
Oct 11, 2024, 6:07:45 PM10/11/24
to Pierpaolo Bernardi, golang-nuts
true is an expression, the compiler doesn’t inspect that it is a constant expression, thus you need the return statement
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANY8u7F3pV_FX3jQHRz%2BOpmrPN0qb6-2-NAwzQYNRe9Qq18D8A%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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANY8u7F3pV_FX3jQHRz%2BOpmrPN0qb6-2-NAwzQYNRe9Qq18D8A%40mail.gmail.com.
Ian Lance Taylor
Oct 11, 2024, 6:34:46 PM10/11/24
to robert engels, Pierpaolo Bernardi, golang-nuts
On Fri, Oct 11, 2024 at 3:07 PM robert engels <ren...@ix.netcom.com> 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.
>
> true is an expression, the compiler doesn’t inspect that it is a constant expression, thus you need the return statement
Ian
> > On Oct 11, 2024, at 4:57 PM, Pierpaolo Bernardi <olop...@gmail.com> wrote:
> >
> > 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?
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANY8u7F3pV_FX3jQHRz%2BOpmrPN0qb6-2-NAwzQYNRe9Qq18D8A%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...@googlegroups.com.
Message has been deleted
Cleberson Pedreira Pauluci
Oct 11, 2024, 11:35:08 PM10/11/24
to golang-nuts
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, but I think this is strictly compiler behavior:
func myfunc() int { if i > 8 {
return i
}
}
}
But the following code will not compile.
if i > 8 {
return i
}
}
}
To fix that (for didactic purposes only), we can add a return statement after the loop (which will never be reached, but satisfies the compiler):
func myfunc() int { if i > 8 {
return i
}
}
return 0 // This line is unreachable but satisfies the compiler
}
If anyone knows more about this behavior, I would be happy to learn more.
Cleberson
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, but I think this is strictly compiler behavior:
func myfunc() int {
for i := 0; ; i++ {
return i
}
}
}
But the following code will not compile.
func myfunc() int {
for i := 0; i <= 9; i++ {if i > 8 {
return i
}
}
}
To fix that (for didactic purposes only), we can add a return statement after the loop (which will never be reached, but satisfies the compiler):
func myfunc() int {
for i := 0; true; i++ {
return i
}
}
return 0 // This line is unreachable but satisfies the compiler
}
If anyone knows more about this behavior, I would be happy to learn more.
Cleberson
Cleberson Pedreira Pauluci
Oct 12, 2024, 12:08:21 AM10/12/24
to golang-nuts
I have encountered the same discussion in the past at https://groups.google.com/g/golang-nuts/c/jP_5kSTmSy4
Pierpaolo Bernardi
Oct 12, 2024, 12:16:57 AM10/12/24
to Cleberson Pedreira Pauluci, golang-nuts
On Sat, Oct 12, 2024 at 5:35 AM Cleberson Pedreira Pauluci
<pauluci....@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.
<pauluci....@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.
Cheers
Robert Engels
Oct 12, 2024, 12:31:04 AM10/12/24
to Pierpaolo Bernardi, Cleberson Pedreira Pauluci, golang-nuts
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, 2024, at 11:16 PM, Pierpaolo Bernardi <olop...@gmail.com> wrote:
>
> On Sat, Oct 12, 2024 at 5:35 AM Cleberson Pedreira Pauluci
> On Oct 11, 2024, at 11:16 PM, Pierpaolo Bernardi <olop...@gmail.com> wrote:
>
> On Sat, Oct 12, 2024 at 5:35 AM Cleberson Pedreira Pauluci
> --
> 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...@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...@googlegroups.com.
Ian Lance Taylor
Oct 12, 2024, 11:04:39 AM10/12/24
to Robert Engels, Pierpaolo Bernardi, Cleberson Pedreira Pauluci, golang-nuts
On Fri, Oct 11, 2024, 9:30 PM Robert Engels <ren...@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 <olop...@gmail.com> wrote:
>
> On Sat, Oct 12, 2024 at 5:35 AM Cleberson Pedreira Pauluci
> <pauluci....@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...@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...@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.
Robert Engels
Oct 12, 2024, 11:08:56 AM10/12/24
to Ian Lance Taylor, Pierpaolo Bernardi, Cleberson Pedreira Pauluci, golang-nuts
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 <ia...@golang.org> wrote:
Peter Weinberger (温博格)
Oct 12, 2024, 11:24:20 AM10/12/24
to Robert Engels, Ian Lance Taylor, Pierpaolo Bernardi, Cleberson Pedreira Pauluci, golang-nuts
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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/024E1FB8-CA78-4F2A-90C9-CFD5C9E2DAC0%40ix.netcom.com.
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.
Robert Engels
Oct 12, 2024, 12:06:02 PM10/12/24
to Peter Weinberger, Ian Lance Taylor, Pierpaolo Bernardi, Cleberson Pedreira Pauluci, golang-nuts
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
> 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
Ian Lance Taylor
Oct 12, 2024, 11:05:30 PM10/12/24
to Robert Engels, Pierpaolo Bernardi, Cleberson Pedreira Pauluci, golang-nuts
On Sat, Oct 12, 2024 at 8:08 AM Robert Engels <ren...@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".
>
> 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.
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
Robert Engels
Oct 13, 2024, 12:10:16 AM10/13/24
to Ian Lance Taylor, Pierpaolo Bernardi, Cleberson Pedreira Pauluci, golang-nuts
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 <ia...@golang.org> wrote:
> On Oct 12, 2024, at 10:05 PM, Ian Lance Taylor <ia...@golang.org> wrote:
Reply all
Reply to author
Forward
0 new messages