Koz Ross

@zmrocze This is based on MLabs discoveries (usually through stuff blowing up). As far as I am aware, they are documented nowhere.

As someone who (unwillingly) has to use an alternative prelude with exactly such a magic conversion function, I am _strongly_ not in favour of it. It often turns type resolution...

@Kleidukos My gripe was with the extremely polymorphic `show` (which as you clarified, isn't part of your original proposal). The one I have to deal with is from `universum`, which...

Not really - the whole point I'm making is that type classes are a bad vehicle for this kind of idea. The way the Relude stuff is written is basically...

The argument that 'we have lawless type classes already, what's a few more' is pretty bad, especially when the existing examples given are some of _the_ most problematic type classes...

@Lysxia I think I was a bit unclear in my argument - sorry! Let me clarify. The issue I have with the UTF-8 conversion type class proposed here isn't (entirely)...

In my experience, type synonyms aren't that great. They're expanded _sometimes_ by GHC (never consistently), which means you can easily end up with confusing messaging from the compiler. This basically...

I agree with @parsonsmatt - lazy Text should go. I would also be quite happy to assist with the necessary writing.

Not to mention that (for `ByteString` at least), there's faster `Builder` implementations that don't rely on the corresponding lazy type. This is quite likely true for `Text` as well. It's...

@Bodigrim I completely disagree. Try using a library which uses lazy `Text` - then you have to interact with it, whether you like it or not. If that's not 'forced',...