Provide strict conversion from ByteString to Text

[mitchellwrosen]

Currently all ByteString -> Text conversions use Data.Text.Encoding.Error.lenientDecode. However, some users might prefer the UnicodeException be thrown instead.

So, I propose an alternative module Data.Conversions.String.Strict, which is a drop-in replacement for Data.Conversions.String, but uses Data.Text.Encoding.Error.strictDecode in the ByteString -> Text instances.

[soenkehahn]

I'm not against adding something that allows strict decoding. Some thoughts:

• There is string-conv. Looks like it allows strict conversion. Err, nevermind, it's implementation seems to be the same as for lenient decoding: http://haddock.stackage.org/nightly-2016-04-20/string-conv-0.1/src/Data-String-Conv.html. That's weird...
• In practice I would usually want to have more control over when validation is happening. Wouldn't it be better to have functions similar to

validate :: ByteString -> Either UnicodeException ByteString

unsafeValidate :: ByteString -> ByteString

This would also compose with Data.Conversions.String.Monomorphic.

• Although the word 'strict' seems to be used in this context it's a bit confusing. I would expect SomeModule.Strict to provide strict (as in strict evaluation) versions of the things in SomeModule. Maybe we can find a better name?
• What about converting ByteStrings to other types, e.g. String? I guess it would be nice if the same exceptions were thrown? What happens currently in case of encoding errors? (Sorry, not addressing these questions at you, @mitchellwrosen. Just something I wonder about.) This would also be solved by unsafeValidate.

Maybe you could elaborate on your exact use-case(s). I have never had the desire to decode anything strictly. That could help to narrow down the design space. Would validate / unsafeValidate even work for you?

[soenkehahn]

@mitchellwrosen: Btw, I just realized in shock that this project doesn't have a test-suite. I added one in #8.

[mitchellwrosen]

• Wow, good catch. That's an incredible copy/paste error. string-conv needs tests! Haha.
• I agree that .Strict is not an ideal name; it would be better if the default module threw UnicodeException and there was a .Lenient alternative.
• A ByteString -> String conversion cannot fail, as far as I know.

My use case is simply wanting to hear invalid utf-8 decodings loudly, whether via an async exception or an Either Bad Good is a matter of taste.

But, in talking with a coworker, I think in this case we're simply going to write our own string conversion typeclass and leave out all ByteString -> Text instances. The programmer will just have to reach for decodeUtf8 manually in these cases.

[mitchellwrosen]

I think I misspoke, another coworker just informed me that ByteString -> String conversions are also unprincipled, as they assume ASCII encoding, and strip wider chars to 8 bits.

[soenkehahn]

Hmm, ideally ByteString -> String would behave similarly to ByteString -> Text when it comes to decoding failures. Thanks for the pointer.

I take it that you're not interested in having this feature anymore, so I'll close. Feel free to reopen, if you want this.