dons@cse.unsw.edu.au (Donald Bruce Stewart) writes: I already voiced this on IRC, but if you'll forgive me, I'll sum up my small minority report.
This separation means there is now an encoding-agnostic Word8 level of high-performance code, which should be generally useful.
I'm very happy with the separation, and I think using the Latin-1 charset as the default is the right choice. The only thing I am unhappy about, is the last minute name change, which means that the interpretation as Latin-1 is no longer explicit to the user. A naive user may think that the anonymously named Char module interprets the locale for instance, or might disregard the character set issues entirely, and be confused when a string literal using characters with code points > 255 don't work as expected. In addition, it is natural to extend this with other character sets, but it is no longer obvious where to put sibling modules implementing the same Char functionality with a different (single byte) encoding. Quite frankly, I don't see any advantage of selecting one particular encoding, and then disguise the fact from the user.
Opinions?
Well, you did ask. Thanks for the good work, I'm currently benchmarking my programs to check what the current Char IO costs are, and if my suspicions are corroborated, I'll spend some time this week to switch. -k -- If I haven't seen further, it is by standing in the footprints of giants