Re: [go-nuts] Reason for "goto jumps over declaration" being disallowed

[Mike Schinkel]

Hi Kurtis,

> Is the code after the "end" label ever going to be more complicated than a 
> simple "return err"? If not then I don't see the point of the goto statements.

Yes, very often. 

I could show examples but don't want to trigger bike shedding.

If you want to see some I'll be happy to send off-list. 

> Also, since you named the return value you can simply do "return" rather than 
> "return err" (personally I'm not a fan of bare returns that implicitly return 
> the named return parameters).

I started using this pattern to avoid multiple return statements which can be 
problematic when you want the debugger to stop before a function returns. If 
you miss breakpointing a return you can waste time chasing your tail.

Most recommend against naked returns so I prefer one set of return values 
instead of many repeating ones.

I have also found other beneficial reasons to use the pattern than just the 
debugging concern, which I can discuss off-list if you like.

> That function can be ten lines (25%) shorter

Length is one useful metric, but there are other metrics I consider too.

> I would argue would be clearer since the reader doesn't have to look at what 
> follows the "end" label.


The pattern has an `end:` label always at or near the only return in the func, 
and (almost) never any other labels so a reader need not look for it 
after recognizing the pattern.
 

-Mike



> On Aug 26, 2023, at 10:51 PM, Kurtis Rader  wrote:
> 
> On Sat, Aug 26, 2023 at 6:02 PM Mike Schinkel  > wrote:
> OTOH, in my quest to provide the simplest example I could, I provided an 
> example that does not expose the use-case I was interested in exploring, 
> unfortunately.
> 
> Let me instead present some real code from my current project, specifically 
> the variable declarations on the lines 35-36 of the `Process()` method of 
> `*FileProcessor` where the variables declared at the top are not referenced 
> after the label:
> 
> https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75
>  
> 
> 
> Is the code after the "end" label ever going to be more complicated than a 
> simple "return err"? If not then I don't see the point of the goto 
> statements. Also, since you named the return value you can simply do "return" 
> rather than "return err" (personally I'm not a fan of bare returns that 
> implicitly return the named return parameters). That function can be ten 
> lines (25%) shorter and I would argue would be clearer since the reader 
> doesn't have to look at what follows the "end" label.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank

-- 
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/3495CCD1-6509-4027-9F2B-082B205E1568%40newclarity.net.

Re: [go-nuts] Reason for "goto jumps over declaration" being disallowed

[Kurtis Rader]

On Sat, Aug 26, 2023 at 6:02 PM Mike Schinkel  wrote:

> OTOH, in my quest to provide the simplest example I could, I provided an
> example that does not expose the use-case I was interested in exploring,
> unfortunately.
>
> Let me instead present some real code from my current project,
> specifically the variable declarations on the lines 35-36 of the
> `Process()` method of `*FileProcessor` where the variables declared at the
> top are not referenced after the label:
>
>
> https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75
>
>
Is the code after the "end" label ever going to be more complicated than a
simple "return err"? If not then I don't see the point of the goto
statements. Also, since you named the return value you can simply do
"return" rather than "return err" (personally I'm not a fan of bare returns
that implicitly return the named return parameters). That function can be
ten lines (25%) shorter and I would argue would be clearer since the reader
doesn't have to look at what follows the "end" label.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD-%3D-nWm917Mujx6spwPwOPwy-Su8AvCr2bATB-2t8Wcsg%40mail.gmail.com.

Re: [go-nuts] Reason for "goto jumps over declaration" being disallowed

[Mike Schinkel]

Hi Ian,

Thank you for the explanation. That makes perfect sense.

OTOH, in my quest to provide the simplest example I could, I provided an 
example that does not expose the use-case I was interested in exploring, 
unfortunately.

Let me instead present some real code from my current project, specifically the 
variable declarations on the lines 35-36 of the `Process()` method of 
`*FileProcessor` where the variables declared at the top are not referenced 
after the label:

https://github.com/newclarity/wpfr/blob/88d1289a90646f59ec4233eed0e421f1eae36332/pkg/wpfr.go#L34-L75

However, your links to https://go.dev/issue/27165 and 
https://go.dev/issue/26058  seems to be addressing 
exactly the concern, so I will follow up with use-cases on those tickets after 
spending enough time with them to determine which one addresses my use-cases 
better.

Again, thank you.

-Mike

> On Aug 26, 2023, at 7:00 PM, Ian Lance Taylor  wrote:
> 
> On Sat, Aug 26, 2023 at 2:11 PM Mike Schinkel  wrote:
>> 
>> Question about disallowing `goto ` jumping over a variable 
>> declaration?
>> 
>> 
>> And please, before bikeshedding opinions about the use of `goto` pro or con 
>> — note that the Go standard library uses `goto` in some places — this 
>> question is purely for me to gain better understanding the choices made with 
>> the Go compiler.
>> 
>> 
>> Question. Was it:
>> 
>> 
>> 1. Somehow logically required by the compiler, and if so can you elaborate 
>> why?
>> 
>> 2. A design decision made, and if so what what the rationale for the design 
>> decision?
>> 
>> 3. A limitation place on GoLang for some other reason, and if so, what and 
>> why?
>> 
>> 
>> I have prepared an example showing use of `goto` that compiles and one that 
>> does not at this playground URL:
>> 
>> 
>> https://goplay.tools/snippet/tSAbWhmiCZK
>> 
>> 
>> Hoping to hear from someone who actually knows why the decision was made as 
>> opposed to someone who might just be guessing at the reason.
> 
> Consider a function like
> 
> func F() {
>goto lab
>x := 1
> lab:
>fmt.Println(x)
> }
> 
> This function is forbidden today.  If it were permitted, what should it print?
> 
> If the answer to that question seems obvious, what about a case like
> 
> func F() {
>goto lab
>x := func() int {
>fmt.Println("setting x")
>return 1
>}()
> lab:
>fmt.Println(x)
> }
> 
> Should that print "setting x"?
> 
> Rather than attempt to answer these kinds of questions, Go simply
> forbids cases like this.
> 
> Note that Go is not the only language with this restriction.  This
> similar C++ function is invalid, because the goto crosses the
> initialization of the variable.
> 
> int f() {
>goto lab;
>int x = 1;
> lab:
>std::cout << x;
>return 0;
> }
> 
> If you are interested in this topic you may be interested in
> https://go.dev/issue/27165 and https://go.dev/issue/26058.
> 
> Ian

-- 
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/B066901D-A60A-4F08-A1BF-D2C307910548%40newclarity.net.

Re: [go-nuts] Reason for "goto jumps over declaration" being disallowed

[Ian Lance Taylor]

On Sat, Aug 26, 2023 at 2:11 PM Mike Schinkel  wrote:
>
> Question about disallowing `goto ` jumping over a variable declaration?
>
>
> And please, before bikeshedding opinions about the use of `goto` pro or con — 
> note that the Go standard library uses `goto` in some places — this question 
> is purely for me to gain better understanding the choices made with the Go 
> compiler.
>
>
> Question. Was it:
>
>
> 1. Somehow logically required by the compiler, and if so can you elaborate 
> why?
>
> 2. A design decision made, and if so what what the rationale for the design 
> decision?
>
> 3. A limitation place on GoLang for some other reason, and if so, what and 
> why?
>
>
> I have prepared an example showing use of `goto` that compiles and one that 
> does not at this playground URL:
>
>
> https://goplay.tools/snippet/tSAbWhmiCZK
>
>
> Hoping to hear from someone who actually knows why the decision was made as 
> opposed to someone who might just be guessing at the reason.

Consider a function like

func F() {
goto lab
x := 1
lab:
fmt.Println(x)
}

This function is forbidden today.  If it were permitted, what should it print?

If the answer to that question seems obvious, what about a case like

func F() {
goto lab
x := func() int {
fmt.Println("setting x")
return 1
}()
lab:
fmt.Println(x)
}

Should that print "setting x"?

Rather than attempt to answer these kinds of questions, Go simply
forbids cases like this.

Note that Go is not the only language with this restriction.  This
similar C++ function is invalid, because the goto crosses the
initialization of the variable.

int f() {
goto lab;
int x = 1;
 lab:
std::cout << x;
return 0;
}

If you are interested in this topic you may be interested in
https://go.dev/issue/27165 and https://go.dev/issue/26058.

Ian

-- 
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/CAOyqgcVuD0-3r37FfFHdBgoTFX7-1QVUY54MYgG0XKjvQVeKnQ%40mail.gmail.com.

[go-nuts] Reason for "goto jumps over declaration" being disallowed

[Mike Schinkel]

Hi All,

Question about disallowing `goto ` jumping over a variable declaration?

And please, before bikeshedding opinions about the use of `goto` pro or con — 
note that the Go standard library uses `goto` in some places — this question is 
purely for me to gain better understanding the choices made with the Go 
compiler.

Question. Was it:

1. Somehow logically required by the compiler, and if so can you elaborate why?

2. A design decision made, and if so what what the rationale for the design 
decision?

3. A limitation place on GoLang for some other reason, and if so, what and why?

I have prepared an example showing use of `goto` that compiles and one that 
does not at this playground URL: 

https://goplay.tools/snippet/tSAbWhmiCZK

Hoping to hear from someone who actually knows why the decision was made as 
opposed to someone who might just be guessing at the reason.

Thank you in advance.

-Mike

-- 
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/B6B94DDC-323C-4C4C-9292-903421EC7103%40newclarity.net.