Hmm, I think you think of context differently from me. For me context is something you use to manage execution. I mostly use it to notify different parts of the program that "you can stop what you are doing now". For instance if you are processing a request and the client went away. Or you have run out of time.
You're talking about context as a way to distribute data? I do that as well. For instance to provide auth/session data to requests, but that's usually just limited to one path in my software that does this. (I agree it is clumsy, but not because it is the "wrong" thing to do, but rather the API feels a bit dodgy).
If you are talking about something like thread-local storage, that's really a very different thing from both the control aspect of context and the request data aspect.
What extra functionality do you want for goroutine control and why do you think Go needs it?
> What annoys me about Context is there's no way to tell if it's honored by the callee.
On the occasions where I've needed that I've used a WaitGroup and done wg.Add(1) at the point where I start goroutines and then have a defer wg.Done() as the first thing in the goroutine. I don't think the functionality belongs in Context. And if you put it there, you'd just end up complicating things.
> And when I'm accepting Context I'm annoyed at having to write handlers for it all through the stack having no idea how/if people will use it.
> On the occasions where I've needed that I've used a WaitGroup and done wg.Add(1) at the point where I start goroutines and then have a defer wg.Done() as the first thing in the goroutine. I don't think the functionality belongs in Context. And if you put it there, you'd just end up complicating things.
I'm not sure this is the same thing. The point of Context is to propagate cancelations or timeouts across multiple layers of your app and libraries, it's not supposed to be useful for directly started goroutines.
You're talking about context as a way to distribute data? I do that as well. For instance to provide auth/session data to requests, but that's usually just limited to one path in my software that does this. (I agree it is clumsy, but not because it is the "wrong" thing to do, but rather the API feels a bit dodgy).
If you are talking about something like thread-local storage, that's really a very different thing from both the control aspect of context and the request data aspect.
What extra functionality do you want for goroutine control and why do you think Go needs it?