proposal: context/v2: update context package

[ianlancetaylor]

This issue is intended to cover ideas about updating the context package for Go 2.

• The current context package leads to stuttering in declarations: ctx context.Context.
• The current Context.WithValue function accepts values of any types, which is easy to misuse by passing, say, a string rather than a value of some package-local type.
• The name Context is confusing to some people, since the main use of contexts is cancelation of goroutines.
• Context values are passed everywhere explicitly, which troubles some people. Some explicitness is clearly good, but can we make it simpler?

See also #24050 and #20280.

[ianlancetaylor]

See also #27982.

[bcmills]

I would add to that list:

• context.WithValue (intentionally) obscures information about the actual inputs required by a function; for example, because those inputs are required by some method of some other parameter. If we're getting real parametricity, it would be preferable to make those requirements explicit at compile time.

[OneOfOne]

The name Context is confusing to some people, since the main use of contexts is cancelation of goroutines.

Related #28017

[josharian]

I have struggled with performance issues in the past with package context, which were tied somewhat to the API. This led to one hack fix and contemplation of some ugly compiler changes (#18493). I’d like any re-think of context to see how lightweight we can make the package so that it can be used in very fine-grained contexts.

[mvdan]

/cc @rogpeppe who I think had some ideas about the design of the API when it was first introduced.

[ianlancetaylor]

See also #28279.

[deanveloper]

Perhaps have go return a one-buffer channel. Closing the channel would cancel the goroutine, and we could have semantics similar to #27982 to check for cancellation. Reading from the channel would read the value that the function returns.

The problem with this, is that there is no way to read multiple return values, which is a pretty big issue. Not quite sure about an elegant way to solve this without having tuple types built-in to the language.

Writing to the channel would unfortunately write to the channel, but if you do stupid things, you should expect stupid behavior. It doesn't have any real use except for breaking your own code. (And we can't have it return a read-only channel if we want to be able to close it)

Context of course would still exist, but it's primary purpose would be for goroutine-local values, rather than cancellation.