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