Copying a comment from CL 349369:

The original change which introduced a Context to Request deliberately made this field unexported and provided no way to set the context for a Request without copying it. A proposal to change this should explain what has changed since then. See in particular rsc@'s comment here:
#14660 (comment)

For the std, the prohibition for context field is reasonable.

But for non-std frameworks that want to be compatible with std Handler, this limits the implementation of non-std frameworks. Although I've found a way here, it wastes more.

The std solution——one or more goroutines per connection, when handling a 1000k scenario, cost huge memory, scheduling, GC, and leads to STW more easily and it even performs obviously worse than java-netty and nodejs. So there are still people of us in the community who try to use the syscall+ poller to solve the 1000k problem, we save a lot of hardware configuration and bring better stability.

I'm sorry, but I don't see what Request.SetContext has to do with numbers of goroutines.

I'm sorry, but I don't see what Request.SetContext has to do with numbers of goroutines.

Sorry for that, I forgot to explain.

Here I want to set the context field, but there's no Request.SetContext method, so I set the whole Request struct with another struct that has the context value.

nbio is a poller framework, it saves goroutines and aims to solve 1000k, also wants to be compatible with std Handler as much as possible, so I want to set the Request.context

Request is explicitly immutable. That's why we have Request.WithContext.

Declining as infeasible (contradicts basic design).

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