Closed phadej closed 2 years ago
My inclination would be to adopt option (2), since lens
defines a similar utf8
function as a Prism
. Fortunately, we don't export strictTextUtf8
, so we can change its implementation as we see fit.
Sorry, I didn't read this closely enough when I wrote my original comment. Option (2) isn't feasible for _Key
, since its type requires a full-blown Iso
, not just a Prism
.
I mainly added the ByteString
instances as a convenience for interoperability with aeson
, so I suppose I did have UTF-8 in mind. In that case, I propose that we add Haddocks to the instances stating that they assume the invariant that the ByteString
s are UTF-8–encoded. We could also switch from using decodeUtf8
to decodeUtf8Lenient
, I suppose, but either way, you'd get unexpected results if you use something that isn't UTF-8–encoded.
I'd favor changing to decodeUtf8Lenient
for _Key
(for _Value
it doesn't really matter, as that shouldn't ever fail). Documenting that it's not full Iso
is :+1:.
See #50.
In
decodeUtf8
is partial, iterror
s if the encoding is not correct.I'm not sure what would be the best way to proceed:
decodeUtf8Lenient
would at least removeerror
(though not make it a trueIso
)I'm leaning to go 1. for
optics-aeson
(2. is also possible), butlens-aeson
could do 3.?EDIT:
strictTextUtf8
is used in_Value
too, but there it's used onaeson
produced bytestrings, which should be valid UTF8, so it's "safe".