There are use cases where storing a Ptr a makes sense and the caller will clean up the memory when done with it. For example, if the caller has a ForeignPtr already you might see code like this:
withForeignPtr ptr $ \p -> do
let pd = PixelData ... p
...
Here, the withForeignPtr will clean up p when done with it and pd should not escape (it is undefined outside of withForeignPtr).
I could also imagine a case where the PixelData is created outside of a withForeignPtr and the creator wants to associate a finalizer with the pointer stored inside. For this reason it may make sense to have a variant of PixelData that supports ForeignPtr.
There are use cases where storing a
Ptr amakes sense and the caller will clean up the memory when done with it. For example, if the caller has aForeignPtralready you might see code like this:Here, the
withForeignPtrwill clean uppwhen done with it andpdshould not escape (it is undefined outside ofwithForeignPtr).I could also imagine a case where the
PixelDatais created outside of awithForeignPtrand the creator wants to associate a finalizer with the pointer stored inside. For this reason it may make sense to have a variant ofPixelDatathat supportsForeignPtr.