Closed vrom911 closed 6 years ago
I agree that having Buildable
instances for both ByteString
and LazyByteString
would be really convenient! Unfortunately, it's not easy to tell, what should be the default implementation of such instance. Because ByteString
is basically a ByteArray
(and a lot of problems can be solved if this data type was named properly). It just happens so that very often ByteString
is used at utf-8
or ascii
encoded text.
Though, it's still not obvious what formatting you prefer... When you format ByteString
"ABC"
do you want to see [65, 66, 67]
or do you want to see "ABC"
? But still, you can specify explicit formatting function for ByteString
but when you have data type with ByteString
inside, like Either Int ByteString
it becomes really hard to deal with such data types. Unfortunately, I didn't find formatting functions for ByteString
neither in text-format
not in formatting
library.
My initial guess is that we should have Buildable
instance for ByteString
. Though I don't really like orphan instances, I don't think this can be avoided for now... I created issue: https://github.com/bos/text-format/issues/20
Maybe we can live with default implementation from ByteString
to String
using unpack
or show
and then to Builder
. I don't see good solution for this problem...
I don't think there's a good default here. My gut says that half of the time it's hex and half of the time it's UTF-8 (or rather, for many applications/domains it's exclusively one or the other, and it all depends on what you're writing).
I'll add utf8F
though.
It's not easy to deal with
ByteString
s infmt
library, as I noticed there is no instanceBuildable
for it...UPD: I found
byteString :: ByteString -> Builder
function from thebytestring
package. Probably it can be reexported infmt
?