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.

[joonas-fi]

I feel that Context only partly solved the problem of cancellation, since there is no facility to wait until the thing we're cancelling, has been cancelled (e.g. wait for the cancelled goroutine to stop). I built a "stopper" for this use case: https://github.com/function61/gokit/blob/dc75639388d554c7f79ca7ec6c967436b6c8301c/stopper/stopper_test.go (disclaimer: I should've made "stopper" a hybrid composed of context - my design is far from good and I plan to improve it)

[deanveloper]

I like this comment: #21355 (comment)

A somewhat less invasive way to reduce the syntactic overhead of Context would be to make it a built-in type (like error).

That would at least cut the stutter by a third:

-func Foo(ctx context.Context) error {
+func Foo(ctx context) error {

I think my only issue with it is that functions that take contexts also typically have a Context in the function name, ie FooContext(ctx context.Context) error would become FooContext(ctx context) error, and we don't save quite as much as we think we do. Either way cutting off the redundancy is nice.

[dayfine]

@deanveloper any example of a FooContext function that actually have 'context' in the name? I haven't seen any of that myself. But context does spread all the way deep into call hierarchy which is sort of horrifying.

[dayfine]

Partially copying my reply in #20280

As someone who has been writing Go for two months. I never really understood context, or had to understand it, even though I see it everywhere and use it everywhere, as required by the code standard to pass it down in call hierarchy as the first argument. Today I am refactoring some code that uses it, and wonder if I can get it removed, so I figured out what context is for for the first time.

It is not immediate obvious for a beginner to understand the purpose context is used for, or to understand that IO would like to use context for cancellation, instead of something else, or that context is a primary mechanism of cancellation at all...

It's simply not self-explanatory enough, and I don't think the terminology is consistent for a developer who also deals with concepts with the same name in a different language. e.g. writing C++ at the same time, I would think Context has server-lifetime instead of request-lifetime.

I think that makes it worthwhile for us to carefully explain what it is to help engineers / new learners understand, and make the package itself as clear as possible. e.g. If it is for request-scoped info, why is it package not named request/context, or maybe it should be concurrency/context? Or if it is really used in conjunction with goroutine, how come it is not part of the language feature?

[The part where I don't know what I am talking about]
I feel like some of the concepts were borrowed from the web, where the functionalities, e.g. canceling an asynchronous operation might be realized by a browser API, i.e. to implement the behavior on call stack alone might not be sufficient, and require invention like this which gets a bit confusing. If that's the reality, we should state the facts very clearly and be crystal clear about the limitation and potential confusions.