proposal: x/net/context: move to the standard library

[Sajmani]

The context package provides a standard interface for passing request-scoped values, deadlines, and cancelation information across package boundaries. Examples of request-scoped values include authentication information, golang.org/x/net/trace.Traces, and Dapper-like distributed tracing IDs. Context is widely used: godoc.org lists 1500+ imports. Context is a critical element in RPC systems like Go-kit's Endpoint interface and gRPC Go.

We (@Sajmani and @bradfitz) would like to incorporate Context into standard library packages (see list below). Standard library packages cannot depend on external packages, so we propose moving the context package into the standard library as package "context".

One complication with moving this package is that interfaces that currently mention golang.org/x/net/context.Context will not be satisfied by implementations that use context.Context. For example, gRPC service implementations will fail to compile if we change the Go protocol compiler to use context.Context. We will need to provide some way to manage this transition.

Potential uses of Context in the standard library:

• Add Context to http.Request to support canceling HTTP requests and passing request-scoped values
• Add Context to net.Dialer to support canceling Dial
• Add Context to functions in database/sql and interfaces in database/sql/driver to support canceling database operations and passing request-scoped values
• Generally, add Context to any function that supports cancelation and may be implemented using RPCs

[Sajmani]

A related proposal is to remove the Deadline method from the Context interface and so remove its dependence on the "time" package. This would permit the Context interface to be used in packages that cannot depend on "time". Context's deadline support would be implemented using a Context value. Callers would access the deadline with a function in a separate package deadline as deadline.FromContext(context.Context) (time.Time, bool). This is a more invasive change than the original proposal; it is only justified if we can identify packages that should use Context but cannot depend on "time".

[adg]

Please write this up as a proposal doc.

[rsc]

Please write a proposal doc. Be sure to mention

• the migration problem
• tradeoffs for what package Context should go into
• a list of what changes would be made in the standard library to use Context

FWIW I don't see any compelling reason to try to eliminate references to package time from the context API. Even if Context were to go into io, it seems okay to me at first glance to make io depend on time.

Thanks.

[gopherbot]

CL https://golang.org/cl/21810 mentions this issue.

[gopherbot]

CL https://golang.org/cl/22101 mentions this issue.

[gopherbot]

CL https://golang.org/cl/22124 mentions this issue.

[josharian]

This got done. Closing.