But the current suggested way for context keys is to
save it into a variable of type interface{} to reduce
the cost of interface conversion?

Why should there be any cost to interface conversion of a struct{} ?
By contrast, there's no cost to converting a pointer to an interface and converting
a known-nil pointer to an interface is even cheaper than copying an
interface AFAICS.

ISTM that the suggested workaround should be unnecessary.
It imposes cognitive overhead because you need to invent two
names rather than one, and because by defining it as an interface
variable, you open up the possibility of it being modified.

FWIW the "current suggested way" as seen in https://blog.golang.org/context is
to use a typed integer constant, which is definitely not ideal as it will incur
an allocation every time it's used.

BTW I think the compiler should probably completely optimize out all "struct{}"-valued variables. Using such a variable could be exactly the same as using a struct{}{} literal. Currently different code is generated for:

interface{}(struct{}{})

and

 var x struct{}
 ...
     interface{}(x)

I don't see any reason that there should be a difference.

That should perhaps be considered another issue though.

See also #17725.
We can certainly avoid the convT2E cost in this case. We could use &zerobase (what malloc returns for zero-sized allocations) instead of nil (not sure if it matters, have to think about it).

type contextKey struct{}
var SomethingKey interface{} = contextKey{}

This is a general way to optimize doing the interface construction only once. Optimizing struct{} won't invalidate that whole pattern. But it does become useless for struct{}. I'm ok with that.

We could use &zerobase (what malloc returns for zero-sized allocations) instead of nil

That already seems to be the case. The pointer value in interface{}(struct{}{}) is the same as &struct{}{}.

Right. But we don't need to call convT2E, which calls mallocgc, which then returns &zerobase. We can just use &zerobase directly.

@randall77 I deleted the post after I made it, I was thinking the conversation was headed around higher level assignment semantics, this makes sense I think:

Right. But we don't need to call convT2E, which calls mallocgc, which then returns &zerobase. We can just use &zerobase directly.

As an additional data point golint checks basic data types for suitability as context keys and explicitly OK's struct{} (golang/lint#245)

Gophetbot still seems ill, so: CL 35562

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