Closed gregwebs closed 9 years ago
I'm a solid +1 on adding errorM
and errorIO
. I'm less certain of switching to Text
. While I agree with you that this would be more consistent, I have a nagging worry that this will cause too much breakage. The reasons I left it as String
in the first place were (1) there's no performance advantage, since we'll need to unpack to String
anyway, and (2) a number of libraries hardcode their error outputs as String
(I think attoparsec does this, for instance).
Anyway, I'm not opposed necessarily, just airing my concerns.
Agreed this is not about performance. I find myself always using Text. But I can change it in my application
for consistency,
error
should be change to useText
. Often times though,error
is used out of convenience in IO when one is not supposed to be using it.errorM
would usethrowM
. I would like to push this upstream, but I don't think there is any upstream that depends onText
.