Re: [go-nuts] Re: Range over int

It's not just changing `k` inside the loop body that makes the transformation invalid -- your observation also applies to modifying `i` inside the loop body. Modifying either variable inside the loop body is extremely rare in my experience and doing so warrants a "dragons be here" comment. Still,

Re: [go-nuts] Re: Range over int

On Fri, Feb 16, 2024 at 10:27 PM Amnon wrote: > But now it is out, I think it is great, and have run > perl -pi -e 's/for (\w+) := 0; \1 < ([\w()]+); \1\+\+/for \1 := range > \2/' $(git grep -l for) over my entire codebase to use it everywhere. > You know your own codebase, and maybe this

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain wrote: > I would argue that the matter can be simply decided by choosing the > *calling* stack, not the destination stack. > I agree that this is *one choice*. But the point is, that *sometimes* you'd want one and *sometimes* the other. And no matter

Re: [go-nuts] Re: Range over int

Indeed. The thread started 12 years ago. At the time I thought the idea of ranging over an int was just dumb, and un-go-like. But now it is out, I think it is great, and have run perl -pi -e 's/for (\w+) := 0; \1 < ([\w()]+); \1\+\+/for \1 := range \2/' $(git grep -l for) over my entire

[go-nuts] Re: Trying to understand aversion to main package

Another motivation I have heard used is that an os.Exit() from main by-passes defer(). So if you need to use defer from a "main-like" context move it to a function called from main(), do your defer(s) in it and then do the os.Exit() from main().. On Friday 16 February 2024 at 01:23:57 UTC-8

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Hey Axel, thanks for the response. /The general reason this has not been accepted for Go, is that passing a Context explicitly removes ambiguities what is meant, in the presence of closures and goroutines./ /If you pass a closure to a different execution context (e.g. via a

Re: [go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

FWIW the common name for this is "dynamic scope": https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynamic_scope The general reason this has not been accepted for Go, is that passing a Context explicitly removes ambiguities what is meant, in the presence of closures and goroutines. If you

[go-nuts] Could we trade all the `ctx context.Context` arguments for one pointer in `g`?

Hi all, Many moons ago I wrote a proposal to make /execution context/ a fundamental concept in Go, effectively moving `context.Context` to being part of the language, not just an extension. The main reason to do this is

[go-nuts] Re: Trying to understand aversion to main package

My main acts just like a mini bootstrap to do as less as possible and hand the real action over to start.Run() But is is still testable. ``` var mainRunner = runner /* -- Methods/Functions -- */ // runner starts the application and can be

Re: [go-nuts] Need help to close/shutdown http server when underlying socket fd explicitly bind used

On Thu, Feb 15, 2024 at 11:30:53AM -0800, Bing wrote: > I'm trying to implement a http server and I need to bind the underlying > socket to a specific VRF instance so that the server only listens on that > VRF instance. When some specific event happens, the program needs to > shutdown the http