Well, one of the reasons is convention. The context should be passes as paramter and be the first paramter as is stated in the package documentation. For sure following the convention it's easier to know where the context came from, when it's available. Inside a struct it's somehow hidden, might not obivious there is a context there, or end up being replaced rather than updated.
It's what I have in my mind. On Wednesday, 25 September 2019 04:43:17 UTC+2, john...@gmail.com wrote: > > I've read the documentation recommended never to store a context in a > struct. I'm curious to know why that's a bad thing. Is it just because > context is request-scoped, and the struct may not be? Or is there more to > it than that? In other words, what can go wrong if you store a context in > a struct? > > > (And what do we actually mean by request-scoped? Do we specifically mean > "a chain of function calls" or do we mean something more conceptual, like a > "request" received by a server?) > -- 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/6e687648-2aa6-4da3-9387-685705ff3fc9%40googlegroups.com.
