search

haskell / primitive

This package provides various primitive memory-related operations.
Other
114 stars 58 forks source link

sizeofSmallMutableArray #373

Closed treeowl closed 1 year ago

treeowl commented 1 year ago

Should we deprecate it now that SmallArrays can shrink in place? I'm not sure. It's a bit bogus, but it still works for code that doesn't use shrinking at all.

treeowl commented 1 year ago

In https://github.com/haskell/primitive/pull/372#issuecomment-1461015632, I wrote

The situation is slightly more complicated than that, I think. Originally, there was no primop for shrinking in place; "resizing" always meant copying. So a pure function for the size was totally fine. Now that there is a shrinking primop, we need to have an IO action to be sure to get the most recent size, rather than one that might be CSEed from earlier. However, it's arguably okay to use it in a program that doesn't use shrinking. Most programs, indeed, don't use shrinking.

That said, deprecation might well be a good idea. The pure/unsafe function definitely smells like a foot-gun.

lehins commented 1 year ago

Same question should also apply to sizeofMutableByteArray

I'd suggest deprecating them in favor monadic counterparts, because whenever one is dealing with a mutable array they are already in a some PrimMonad, so this is not much of an inconvenience, but definite improvement with respect to safety.

chessai commented 1 year ago

I'm in favour of deprecating both.

andrewthad commented 1 year ago

I agree that we should deprecate these. Both can give incorrect answers (possibly leading to memory corruption), and even worse, their behavior is dependent on the optimization level (floating in/out past a shrink causing the issue). I cannot think of any situation in which using either of these functions is desirable.

konsumlamm commented 1 year ago

This has been addressed in #387.