proposal: context: implement NewContext and FromContext with generics

[zensh]

We can implements a very concisely NewContext and FromContext functions with generics:

package context

import "internal/reflectlite"

func NewContext[T any](parent Context, v *T) Context {
	return WithValue(parent, reflectlite.TypeOf((*T)(nil)), v)
}

func FromContext[T any](ctx Context) *T {
	v, _ := ctx.Value(reflectlite.TypeOf((*T)(nil))).(*T)
	return v
}

It will be very useful:

// define User
type User struct {...}

// set user into ctx
user := &User{...}
ctx := context.NewContext(context.Background(), user)

// get user from ctx
user := context.FromContext[User](ctx)

[ianlancetaylor]

See also #49189.

[ianlancetaylor]

CC @Sajmani @dsnet

[zensh]

CC @neild

[zensh]

Maybe we can add a helper function:

func DoIfValid[T any, V interface {
	*T
	Valid() bool
}](ctx Context, fn func(v *T)) {
	if v := FromContext[T](ctx); V(v).Valid() {
		fn(v)
	}
}

[zensh]

Better naming:

context.ValueInto[T any](parent Context, v *T) Context
context.ValueFrom[T any](ctx Context) *T

[Sajmani]

I don't see the benefit of context.NewContext: it's not safer or more concise over the existing context.WithValue function.

The context.FromContext function moves the type assertion inside the function and returns nil if the assertion fails. This seems less safe to me than what people do today, as it skips the error handling that users should be doing.

[zensh]

@Sajmani Thanks for your comment.

It can simplify code for so many go apps, even the go source itself.

Here is a example, people must to define a private type, a private variable as context key and two functions to manipulate it:

go/src/context/context.go

Line 142 in 8bcc490

// type key int

We can now eliminate these duplicate code definitions if golang provides a generic version.

Also, I think this is one of the best examples of using generics.

[zensh]

it maybe returns a bool to indicate the assertion fails. I just don't think it's necessary. A nil *T can indicate assertion fails.

context.ValueFrom[T any](ctx Context) (*T, bool)

[Sajmani]

I see: this function associates a value with a context using the value's reflect.Type as the key. I agree this is convenient.

The problem with this is that two packages that are unaware of each other might try to associate the same type with a context, such as a Logger or database handle. If the programmer is not aware of this possibility, this could lead to very strange bugs.

We could provide guidance that this feature should only be used with a package's own types, but I think many people will be tempted by the convenience to misuse this feature.

In my opinion the risks outweigh the benefits, but I'm willing to hear from others.

[zensh]

@ianlancetaylor @dsnet @neild
Does anybody like this proposal? If nobody like it, I will close the issue.

I have used it in my projects:

https://github.com/ldclabs/ldvm/blob/main/util/value/context.go#L12

https://github.com/teambition/gear/blob/master/context.go#L41

[ianlancetaylor]

I don't see a lot of support for this proposal, and it can be implemented outside of the standard library. Perhaps it should be an external package for now, and we can consider adopting it into the standard library if it sees wide use.

[rsc]

This proposal has been declined as retracted.
— rsc for the proposal review group