Go Optimization Guide

    pool := sync.Pool{
        New: func() any { return 42 }
    }

    a := pool.Get()

    pool.Put("hello")
    pool.Put(struct{}{})

    b := pool.Get()
    c := pool.Get()
    d := pool.Get()

    fmt.Println(a, b, c, d)

Is a type system all that helpful if you have to keep turning it off any time you want to do something even slightly interesting?

Also I can't help but notice that there's no API to reset values to some initialized default. Shouldn't there be some sort of (perhaps optional) `Clear` callback that resets values back to a sane default, rather than forcing every caller to remember to do so themselves?

> Also I can't help but notice that there's no API to reset values to some initialized default.

That's what the New function does, isn't it?

BTW, the code you posted isn't syntactically correct. It needs a comma on the second line.

But that's only run when the pool needs to allocate more space. What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does.

I think Golang's implementation does make sense, as sync.Pool() is clearly an optimization you use when performance is an issue; and in that case you almost certainly want to only initialize parts of the struct that are needed. But I can see why it would be surprising.

> [any] is a type

It's typed the way Python is typed, not the way Rust or C are typed; so loses the "if it compiles there's a good chance it's correct" property that people want from statically typed languages.

I don't use sync.Pool, but it does seem like now that we have generics, having a typed pool would be better.

One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees:

  type Pool[T any] sync.Pool  // typed def

  func (p *Pool[T]) Get() T { // typed Get
      pp := (*sync.Pool)(p)
      return pp.Get().(T)
  }

  func (p *Pool[T]) Put(v T) { // typed Put
      pp := (*sync.Pool)(p)
      pp.Put(v)
  }

  intpool := Pool[int]{        // alias New
      New: func() any { var zz int; return zz },
  }

  boolpool := Pool[bool]{      // alias New
      New: func() any { var zz bool; return zz },
  }

So long as that one is not you? You completely forgot to address the expectation:

    type Foo struct{ V int }
    pool := Pool[*Foo]{ // Your Pool type.
        New: func() any { return new(Foo) },
    }

    a := pool.Get()
    a.V = 10
    pool.Put(a)

    b := pool.Get()
    fmt.Println(b.V) // Prints: 10; 0 was expected.

> 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.

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.

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.

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?

> 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.

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?

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).

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?

I think you should re-read what I wrote. You seem to be upset that I did not solve everyone's problem with sync.Pool with my 10 liner (when I claimed no such thing).

  One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees