proposal: context: add Root as an alias for Background

[matttproud]

This proposal is probably best suited for Go 2 due to Go 1 stability guarantee, but hear me out:

I would like to propose we rename context.Background to context.Root. The reason is due to seeing context.Background's accidental misuse overuse in program and operation leaves. The documentation, to wit:

It is typically used by the main function, initialization, and tests, and as the top-level Context for incoming requests.

I have a supposition on why: the term "background" does not easily lend itself to being understood as a program or operation root; whereas all of the things in the quoted excerpt above can be thought of as either a program root or an operation root. Granted English has no formal authority on usage of vocabulary, but if we compare the definitions offered by Merriam Webster, it becomes more clear that background is inappropriate

• background: I've always felt the name "background context" as we use it today hearkened from the idea of "background radiation", but that metaphor has limited value.

• root: At least three subdefinitions of "root" match the idea of what a background context is, and we also have deep precedent in the collective knowledge of software engineering with "search roots", "root directories", etc.

My feeling is a rename would prevent a lot of misunderstanding and minimize the urgency for static analysis to flag its accidental misuse. It'd help the ecosystem. I say this bringing my experience using the API since its inception in 2014 and helping thousands of engineers use the language.

[changkun]

Why this is not enough?

package mycontext

import "context"

var Root = context.Background

Use:

mycontext.Root()

[ianlancetaylor]

Yes, getting rid of Background would be extremely painful, but adding Root and then deprecating Background is straightforward if we think that is a good idea. Retitled the proposal.

[ianlancetaylor]

CC @Sajmani

[matttproud]

@changkun, I appreciate the consideration. There remain two suboptimal points that would need be solved, however:

1. It is at best a local-optimization, which means it cannot be applied to the overall Go ecosystem as a whole. The whole of Go deserves this improvement; and for me personally in my day job, not one project needs this but rather a uncountable panoply of independent projects.
2. It presents a fragmented solution, which means it is not universally discoverable. Users will wonder which to use or know about one and not the other, which is exacerbated by the existence of two construction functions in separate packages for such a intrinsic ecosystem API.

@ianlancetaylor, I had given consideration to exactly what you propose as well. If you folks are OK with it, I would be as well. The deprecation protocol is well enough understood these days to do the change.

[Sajmani]

This is the first I'm hearing that context.Background is a confusing name. While I appreciate the brevity of context.Root, I expect the confusion that will arise from such a renaming far outweighs the benefit.

[deltamualpha]

"background context" is definitely an idiomatic phrase in American English, meaning basically "how we got to this point". There's no sense that there can only be one of these, whereas Root carries an implication that a programmer should only have a single "root" context from which all other contexts in their application derive, which, while appropriate in some circumstances, seems too prescriptive. I think making this change now would only serve to churn code and tutorials for no real appreciable benefit.

[davecheney]

context.Background is already a synonym for context.TODO. Is adding a third alias going to make a meaningful improvement?

[dominikh]

context.Background is already a synonym for context.TODO

How do you figure?

[davecheney]

context.Background is already a synonym for context.TODO

How do you figure?

Oh dear. Please accept my apologies, I had in my mind that one called the other, perhaps it did at one point in the past, but that is no correct. https://cs.opensource.google/go/go/+/master:src/context/context.go;l=208

[rsc]

I'm very confused about this.
Why would people misuse/overuse Root any less frequently than they misuse/overuse Background?
More generally, there's already a name that people know and that has been used in books, blog posts, and so on.
The bar for just changing to a new name is pretty high. I don't see the evidence for that here.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[matttproud]

Sorry for being a bit incommunicado since filing this issue. It’s been a hectic couple of weeks. Let me confer with some peers on the above, and we can determine next steps.

[matttproud]

In terms of broad strokes, my ideal preference would be to rename the API in the so-called Go 2 (in other words, removing the name Background from package context). That said, there may be a few incremental improvements that can be made in the intervening time, inexhaustively:

• alias API (duplication) — as Ian mentions, which can be done before a Go 2.
• documentation improvements — we could make the package's documentation more concrete.

I think the temporal aspect of when what should be done is confounding the discussion.

In terms of measuring confusion and misuse, I did some examination of our monorepo and comments that were made in code review. We've internally had guidance about avoiding extraneous background context usage in non-roots for about 18 months. In that time, code reviewers flagged about 2,500 instances erroneous context.Background usages.

Why would people misuse/overuse Root any less frequently than they misuse/overuse Background?

Everything's in the name. As I outlined in the opening description, "background" doesn't have a particularly clear meaning nor implication nor insinuation that it is — well — the root from which all things are derived (the very beginning). For better or for worse, in the domain of computing, root is an unambiguous and established term. My expectation is that with a better name developers would think twice: is this place (where I am using the context API) really the root of the operation?

[deltamualpha]

What was the erroneous use? That they should have been using a context that had been passed to them? I don't see how renaming it helps that case.

[matttproud]

There are numerous problem classes in descending order of frequency:

1. Defining greenfield functions where instead of accepting a context parameter, the function locally defines a context inside of it. Most of these new functions would be called in a place where the caller would already have a context and want to control deadline and interruption semantics in addition to using the context for side-channel data passing (e.g., tracing).

   // being added right now
   func greenfield() (*T, error) {
     ctx := context.Background()
     ...
   }
   
   // old code
   func brownfield(ctx context.Context) {
     t, err := greenfield()
     ...
   }

   Instead this code should look like this:

   // being added right now
   func greenfield(ctx context.Context) (*T, error) {
     ...
   }
   
   // old code
   func brownfield(ctx context.Context) {
     t, err := greenfield(ctx)
     ...
   }

This item is self-standingly concerning one.

2. Detachment from a parent context and continuing an operation out-of-band

   proposal: context: add API for performing tasks after Context is Done #19643

   context: add WithoutCancel #40221

   This one can be handled through the above proposals, but it's a specialization.

3. Ignoring that a local context (e.g., function parameter) already exists and calling context.Background to create another.

   func careless(ctx context.Context) {
     ...
     f(context.Background())  // woops; should have used ctx
     ...
   }

[rsc]

Will leave this open for another week, but I still don't see any significant inherent difference between the words Background and Root. Neither is terribly meaningful on its own. They will have the meaning we assign to them in docs and such.

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group