alt Hacker News> What will go wrong if one stores a Context in a struct?
Contexts are about the dynamic contour, i.e. the dynamic call stack. Storing the current context in a struct and then referring to it in some other dynamic … context … is going to lead to all sorts of pain: timeouts or deadlines which have already expired and/or values which are no longer pertinent.
While there are some limited circumstances in which it may be appropriate, in general it is a very strong code smell. Any code which passes a context should receive a context. And any code which may pass a context in the future should receive one now, to preserve API compatibility. So any exported function really should have a context as its first argument for forwards-compatibility.
Except Contexts provide a cancellation mechanism which can be used outwith of a specific dynamic call graph.
The documented semantics of the facility (and the implementation) seemed perfect for destroying a dynamic graph of CSP elements, which were exchanging messages. Where the cancellation causes the goroutines within the (think Actor-like) CSP element to clean up, tear down, and exit.
The warning about not storing it in a struct seems to assume it can only be used for one specific type of purpose, say web server processes and/or related database requests.
If I hadn't used it, I would have had to create something almost identical - but without the ability to store a data element.