Closed Bodigrim closed 9 months ago
I had the same idea the moment you released the byte-array
package.
This way we can shave off dependency on bytestring and do not impose it on our users.
I don't think this is terribly important, in fat I'd be against it, especially considering that bytestring
is one of the wired-in packages. I'd be against it because ability to generate ByteString
and ShortByteString
efficiently out of the box is a great feature. I've personally used it on multiple occasions, including at work (which is not gonna show up at hackage search).
That being said, I do agree with you 100% requiring in RandomGen
:
genByteArray :: Int -> g -> (ByteArray, g)
instead of
and
uniformByteArray :: Int -> g -> m ByteArray
instead of
in StatefulGen
Makes a lot of sense.
ShortByteSring
variants can just be extracted into standalone functions.
+1 for switching to ByteArray
. As for dropping dependency on bytestring
I see no reason to do so. It's basically a part of a standard library
Since
bytestring-0.12
ShortByteString
is just a newtype overByteArray
, a common data type shared bybase
,text
andprimitive
.I think we can make
class Random
more useful if we swapThis way we can shave off dependency on
bytestring
and do not impose it on our users.There does not seem to be many users of
genShortByteString
in the wild. Potentially we can provide a compatibility shim: