You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose adding a new function to the context package. It would have an implementation similar to errors.New, so roughly
package context
typekeystruct {
sstring
}
func (k*key) String() string {
returnk.s
}
// NewKey returns a new value, formatting as s, suitable as a key for use with WithValue.// Each call will return a distinct value even if the text is identical.funcNewKey(sstring) interface{} {
return&key{s}
}
Rationale:
The current recommended best-practice for context-Keys is to create a new, unexported type and use a value of that type as a key. This requires boiler-plate, in particular if you want the key to format nicely. With this, creating a key would just be var myCtxKey = context.NewKey("foo"), to provide the same benefits.
It's just a small quality of life improvement. And having a standard, trivially discoverable way to create context-keys also prevents people from accidentally using unsuitable keys. This could, of course, also live outside the stdlib (and it probably already does) but I would imagine that the improvement is small enough to not really be worth searching for and importing an extra package for it (at least it isn't to me).
I fully understand if the benefits are deemed to small, of course. Just thought I'd suggest it :)
The text was updated successfully, but these errors were encountered:
Is formatting context keys common? I've definitely never felt compelled to print a context key and IMO they should be treated as totally opaque.
I think I'm on board with a context.NewKey function since having first class support for creating keys might make it harder for people skimming the documentation to do the wrong thing (implement collision-prone or memory-allocating keys), but I would probably prefer it to just be context.NewKey(). If your key needs more functionality, you can implement it yourself.
@ccbrownfmt formats contexts, if you print them - they implement Stringer. Though while I assumed that it formats the key, TIL, it actually just prints the type's name. Either way, you'd want a way to disambiguate keys returned by NewKey when formatting a context. IMO a string-argument would be fine, but another possibility might be to use NewKey caller's location (maybe package and file/line-no or something) and yet another (more opaque) would be to use the address.
Personally I don't super care about if and how it formats. I just don't want to have to define new types as context keys :)
I would like to propose adding a new function to the context package. It would have an implementation similar to
errors.New
, so roughlyRationale:
The current recommended best-practice for context-Keys is to create a new, unexported type and use a value of that type as a key. This requires boiler-plate, in particular if you want the key to format nicely. With this, creating a key would just be
var myCtxKey = context.NewKey("foo")
, to provide the same benefits.It's just a small quality of life improvement. And having a standard, trivially discoverable way to create context-keys also prevents people from accidentally using unsuitable keys. This could, of course, also live outside the stdlib (and it probably already does) but I would imagine that the improvement is small enough to not really be worth searching for and importing an extra package for it (at least it isn't to me).
I fully understand if the benefits are deemed to small, of course. Just thought I'd suggest it :)
The text was updated successfully, but these errors were encountered: