On Saturday, September 26, 2020 at 12:34:37 PM UTC-7 Ian Lance Taylor wrote:
> > A Go-style goroutine-local system can be thought as a context.Context > that is transparently assigned to a goroutine and its children. Thus if you > want to change the value, you'd do something like "c := > magic.GetCurrentContext(); c = c.WithValue(...); magic.SetContext(c);". > > This would affect only the current goroutine going forward, but not its > children. > In general, Go's attitude is that explicit is better than implicit. > If you rigorously stick to the pattern you describe, it's the same as > passing the context.Context around explicitly (except that passing the > Context around explicitly is more flexible). > Well, I ran a simple regexp grep over my existing code base. Out of 8153 functions I have 7632 functions that have context.Context as a parameter. So basically in my Go code every function has to have about half a line of extra fluff (context and the error return). I'm ambivalent about goroutine-specific variables. Context is not a terribly bad solution, I can personally live with it just fine. Unfortunately, there are _STILL_ APIs that don't have context. I was bitten by JSON marshalling and SQL. And apparently newer APIs are being designed by the Golang team that don't accept a context (because it doesn't look nice). -- 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/0371c088-7056-45ac-8f1f-e45f5b82b4c5n%40googlegroups.com.
