There's been some discussion about how context.Context should be used. It seems like this proposal could cause misuse by having users think of context with in ways totally unrelated to lifecycle management.

This experience report has some insights on this:

While opinions differs on many aspects of context.Context, one thing is clear–there is almost unanimous agreement that the Context.WithValue method on the context.Context interface is orthogonal to the type’s role as a mechanism to control the lifetime of request scoped resources.

@davecheney what do you think?

My specific use case is for propagating OpenCensus tags, trace and span IDs into a goroutine with a different lifetime from the parent. These are all stored as values in the context, and have separate getters and setters, so you end up with things like

ctx = trace.NewContext(tag.NewContext(context.Background, tag.FromContext(ctx)), trace.FromContext(ctx))

This still doesn't include other values you may want to propagate either, so it only feels like a bandaid.

Context is an interface, so you can always write a new Context implementation that falls back to the old context for value lookups. Is that enough? If so, this is a duplicate of #26691. It's still not clear this must be added to the standard library when it's so easy to implement outside.

/cc @neild @bcmills @Sajmani

Interesting point, that definitely makes sense and it could be implemented wherever it's needed. I'm happy enough with that so this can be considered a duplicate.

Closing per last comment. Thanks.