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?
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).
> 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?
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
Meant... One could define / extend sync.Pool to get those guarantees [for their custom types] ... Followed by an example for int & bool types (which are copied around, so pooling is ineffective like you say, but my intention was to show how sync.Pool could be extended, and nothing much else).
You "forgot" to copy the colon from the original statement. A curious exclusion given the semantic meaning it carries. Were you hoping I didn't read your original comment and wouldn't notice?
> You seem to be upset
How could one ever possibly become upset on an internet forum? Even if for some bizarre and unlikely reason you were on the path to becoming upset, you'd turn off the computer long before ever becoming upset. There is absolutely no reason to use this tool if it isn't providing joy.
> One could define / extend sync.Pool to get those guarantees [for their custom types] ...
What audience would be interested in this? Is there anyone who understands all the intricacies of sync.Pool but doesn't know how to define types or how to write functions?
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?