4 Months Ago
Update: Constraining Pool.Free - Step one * Primary Pool.Free overload now only accepts IPooled types * Secondary overloads added to work with collections (not restricted to IPooled yet). They all call Clear() on the returned pooled container. * Pool.FreeList now just pipes to one of Pool.Free secondary overloads (proper cleanup will be done later - there's 800 occurances of FreeList usage) * Added Pool.FreeUnmanaged as an escape hatch for types that are in the pool but don't implement IPooled interface. Motivation: If we want to avoid leaking memory and reduce potential of "improperly-recycled" pooled objects, so we need a more controlling API for Pool that allows users to avoid misusing it and calling the wrong API by accident. We'll get there by providing a stricter API that checks for users whether it's legal to use it in a particular way. This means I have to write a bunch of boilerplate (overloads + variations) and clean up all the use cases we have(both the types that might benefit from IPooled and all the API usage points). Tests: built all targets for scripts in editor. Didn't do any runtime testing as there's only 1 safe functional change (clearing of collection on return to pool).