5 ms·

> You completely forgot to address the expectation > fmt.Println(b.V) // Prints: 10; 0 was expected. Sorry, I don't get what else one expects when pooling poi

> You completely forgot to address the expectation > fmt.Println(b.V) // Prints: 10; 0 was expected. Sorry, I don't get what else one expects when pooling pointers to a type? In fact, pooling *[]uint8 or *[]byte is common place; Pool.Put() or Pool.Get() then must zero its contents.

9rx 2y ago
> I don't get what else one expects when pooling pointers to a type? As seen in your previous comment, the expectation is that the zero value will always be returned: "What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does." To which you offered a guarantee. > Pool.Put() or Pool.Get() then must zero its contents. Right. That is the solution (as was also echoed in the top comment in this thread) if one needs that expectation to hold. But you completely forgot to do it, which questions what your code was for? It behaves exactly the same as sync.Pool itself... And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples.
- ignoramous 2y ago
  > And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples. If those constraints don't hold (like you say) it should manifest as runtime panic, no? > What GP seems to expect is that sync.Pool() would always return a zeroed structure Ah, well. You gots to be careful when Pooling addresses. > But you completely forgot to do it, which questions what your code was for? OK. If anyone expects zero values for pointers, then the New func should return nil (but this is almost always useless), or if one expects values to be zeroed-out, then Pool.Get/Put must zero it out. Thanks for the code review.
  - 9rx 2y ago
    > If those constraints don't hold (like you say) it should manifest as runtime panic, no? No. Your int and bool pools run just fine – I can't imagine you would have posted the code if it panicked – but are not correct. > I did not forget? Then your guarantee is bunk: "One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees:" Why are you making claims you won't stand behind?
    - ignoramous 2y ago
      It was a blueprint. Embedding and typedefs are ways to implement these guarantees. And of course, writing a generic pool library is not what I was after. > but are not correct. I don't follow what you're saying. You asserted, "And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples." What does it even mean? I guess, this bikeshed has been so thoroughly built that the discussion points aren't even getting through.
      - deleted 2y ago
        [deleted]
      - 9rx 2y ago
        > What does it even mean? Values are copied in Go. Your code will function, but it won't work. You've left it up to the user of the pool to not screw things up. Which is okay to some degree, but sync.Pool already does that alone, so what is your code for?
        ignoramous 2y ago
        > Values are copied in Go Gotcha. Thanks for clearing it up. > so what is your code for? If that's not rhetorical, then the code was to demonstrate that sync.Pool could be "extended" with typedefs/embeds + custom logic. Whether it got pooling itself right was not the intended focus (as shown by the fact that it created int & bool pools).
        9rx 2y ago
        > then the code was to demonstrate that sync.Pool could be "extended" with other types and custom logic. Wherein lies the aforementioned guarantee? The code guarantees neither the ask (zero values) nor even proper usage if you somehow didn't read what you quoted and thought that some kind of type safety was the guarantee being offered. Furthermore, who, exactly, do you think would be familiar enough with Go to get all the other things right that you left out but be unaware of that standard, widely used feature?

9rx 2y ago

> I don't get what else one expects when pooling pointers to a type? As seen in your previous comment, the expectation is that the zero value will always be returned: "What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does." To which you offered a guarantee. > Pool.Put() or Pool.Get() then must zero its contents. Right. That is the solution (as was also echoed in the top comment in this thread) if one needs that expectation to hold. But you completely forgot to do it, which questions what your code was for? It behaves exactly the same as sync.Pool itself... And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples.

ignoramous 2y ago
> And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples. If those constraints don't hold (like you say) it should manifest as runtime panic, no? > What GP seems to expect is that sync.Pool() would always return a zeroed structure Ah, well. You gots to be careful when Pooling addresses. > But you completely forgot to do it, which questions what your code was for? OK. If anyone expects zero values for pointers, then the New func should return nil (but this is almost always useless), or if one expects values to be zeroed-out, then Pool.Get/Put must zero it out. Thanks for the code review.
- 9rx 2y ago
  > If those constraints don't hold (like you say) it should manifest as runtime panic, no? No. Your int and bool pools run just fine – I can't imagine you would have posted the code if it panicked – but are not correct. > I did not forget? Then your guarantee is bunk: "One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees:" Why are you making claims you won't stand behind?
  - ignoramous 2y ago
    It was a blueprint. Embedding and typedefs are ways to implement these guarantees. And of course, writing a generic pool library is not what I was after. > but are not correct. I don't follow what you're saying. You asserted, "And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples." What does it even mean? I guess, this bikeshed has been so thoroughly built that the discussion points aren't even getting through.
    - deleted 2y ago
      [deleted]
    - 9rx 2y ago
      > What does it even mean? Values are copied in Go. Your code will function, but it won't work. You've left it up to the user of the pool to not screw things up. Which is okay to some degree, but sync.Pool already does that alone, so what is your code for?
      - ignoramous 2y ago
        > Values are copied in Go Gotcha. Thanks for clearing it up. > so what is your code for? If that's not rhetorical, then the code was to demonstrate that sync.Pool could be "extended" with typedefs/embeds + custom logic. Whether it got pooling itself right was not the intended focus (as shown by the fact that it created int & bool pools).
        9rx 2y ago
        > then the code was to demonstrate that sync.Pool could be "extended" with other types and custom logic. Wherein lies the aforementioned guarantee? The code guarantees neither the ask (zero values) nor even proper usage if you somehow didn't read what you quoted and thought that some kind of type safety was the guarantee being offered. Furthermore, who, exactly, do you think would be familiar enough with Go to get all the other things right that you left out but be unaware of that standard, widely used feature?