[Someone]

That's exactly the complaint. You don't use a connection pool to get rid of allocs and frees, but to get rid of lengthy calls that initialise the connection. Because of that, you don't want to close your connection before returning it to the pool. So, the pool will have to close those connections whenever it disposes of an object in the pool.

I don't know enough go to interpret what 'might be deallocated' means in this part of http://tip.golang.org/pkg/sync/#Pool:

"Any item stored in the Pool may be removed automatically at any time without notification. If the Pool holds the only reference when this happens, the item might be deallocated."

Is there some interface{} similar to C++ destructors, or is that a reference to the fact that the garbage collector need not deallocate unreachable objects?

[mediocregopher]

There's not a destructor method like there is in C++. I'm not sure why they defined Pool to only interact with interface{}, it seems like it would have been much easier to define an interface which looks like:

  type PoolObject interface {
      Destroy()
  }

And have it interact with that. The NewPool func would look like:

  func NewPool(func() PoolObject) Pool

EDIT: Changed my code a bit