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

Thanks for your examples!  I'll cover them in reverse order, to build up the syntax. On 2/29/24 6:18 AM, 'TheDiveO' via golang-nuts wrote: The second example is unit test code, so TEST:

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

Hey, thanks for raising this important use case.  Do you have any specific examples in mind you could point to? I think the answer should follow easily from what defines a new scope.  New scopes get their own mini-stack frame created, and in that frame the context pointer can be saved like

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

Hi! One more thing to keep in mind for the proposal: sometimes we need to merge two contexts. https://github.com/golang/go/issues/36503 https://github.com/golang/go/issues/57928 -- WBR, Alex. -- You received this message because you are subscribed to the Google Groups

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

On Wed, Feb 21, 2024 at 1:36 AM Sam Vilain wrote: > I had a brief look on the Golang issues in Github and could not find any > prior proposals along this line using "context" and "dynamic scope" as > search terms, so I'll submit this as a "new" proposal for now > FWIW some prior discussion on

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

That is a good reason as to why putting timeouts and cancellation in the “context” always felt wrong to me. These are per request notions - and creating a new context to specify them seems off. But as I mentioned in the other post, without a concept of security context it doesn’t matter much -

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

https://go.dev/issue/21335 - sean On Wed, Feb 21, 2024, 00:36 Sam Vilain wrote: > Alright, well thanks for your input. > > I do think these questions can be answered; exploring the use cases in a > proposal format should hopefully show that the impact of closures would not > normally be an

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

Forgive me if I missed that, but what if I have multiple context vars, because I need to pass different (derived) contexts into different functions/receivers? Take unit tests as real-world examples. On Wednesday, February 21, 2024 at 1:37:05 AM UTC+1 Sam Vilain wrote: > Alright, well thanks

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

FWIW, I think having a bound context to an execution context is a valuable addition. One thing about Go that has always felt lacking is dynamic code loading execution. There is the plugin facility but it doesn’t seem to have been widely adopted. If it were, I think the Go team would find it needs

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

Alright, well thanks for your input. I do think these questions can be answered; exploring the use cases in a proposal format should hopefully show that the impact of closures would not normally be an issue.  Possibly the worst case is if you had a library to some external service, and at

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

If I may quote myself: > And no matter which choice you make for the language - it means that if the programmers wanted the other, they'd have to jump through annoying hoops and get confusing and hard to debug problems. Having a mechanism to get one or the other semantic doesn't change the fact

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

On 2/17/24 1:32 AM, Axel Wagner wrote: 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

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] 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