On Thu, Jan 7, 2021 at 10:20 AM Axel Wagner
wrote:
>
> Hi,
>
> this works fine, but it incurs an extra allocation (AFAIK both for storing
> the data, and for looking it up). requestContext is not zero-sized, so to
> store it in an interface{}, a new value must be allocated and put into the
> in
Hi,
this works fine, but it incurs an extra allocation (AFAIK both for storing
the data, and for looking it up). requestContext is not zero-sized, so to
store it in an interface{}, a new value must be allocated and put into the
interface. This also has to happen on lookup (I don't think the compil
On Thu, Jan 7, 2021 at 10:01 AM Axel Wagner
wrote:
>
> Why do you need fields? If you need fields, you are likely putting too many
> things into your context (note, that the lookup is O(N), with N being the
> number of distinct keys - so you want the number of distinct keys to be
> small). The
Why do you need fields? If you need fields, you are likely putting too many
things into your context (note, that the lookup is O(N), with N being the
number of distinct keys - so you want the number of distinct keys to be
small). The intended use of `context.WithValue` is to only have one key per
"
On Thu, Jan 7, 2021 at 9:48 AM Axel Wagner
wrote:
>
>
>
> On Wed, Jan 6, 2021 at 11:39 PM Amit Saha wrote:
>>
>> Is it fair to say then that any user-defined type here is acceptable as a
>> key?
>
>
> No. You can create a user-defined type out of *any* type T, by just writing
> `type X T`. In p
On Wed, Jan 6, 2021 at 11:39 PM Amit Saha wrote:
> Is it fair to say then that any user-defined type here is acceptable as a
> key?
>
No. You can create a user-defined type out of *any* type T, by just writing
`type X T`. In particular, you can write `type X func()` and get an
incomparable user-
On Thu, Jan 7, 2021 at 9:33 AM Axel Wagner
wrote:
>
> On Wed, Jan 6, 2021 at 11:31 PM Amit Saha wrote:
>>
>> In the description of context.WithValue(), we have:
>>
>> The provided key must be comparable and should not be of type string
>> or any other built-in type to avoid collisions between pac
On Wed, Jan 6, 2021 at 11:31 PM Amit Saha wrote:
> In the description of context.WithValue(), we have:
>
> The provided key must be comparable and should not be of type string
> or any other built-in type to avoid collisions between packages using
> context. Users of WithValue should define their
In the description of context.WithValue(), we have:
The provided key must be comparable and should not be of type string
or any other built-in type to avoid collisions between packages using
context. Users of WithValue should define their own types for keys. To
avoid allocating when assigning to a