I'm still puzzled whether there are other use cases where it would be beneficial to have `display` in the class.
Any case where there are functions already defined in terms of Text that `displayBuilder` is simply wrapping.
Just to properly understand that point, in that cases I could still try to remedy this with rewrite rules (with the limitations you mentioned above), right? Or is there an other aspect to it?
BTW, one nice thing that I think we can do if we do not have `display` in the class is providing versions for strict and lazy text [1]. Technically I think this is also possible if `display` is part of the class definition, but then you run into name clashes if you want to export the full class from both Data.Display and Data.Display.Lazy.
Why not have `display` and `displayLazy`, or something like that?
That would leave us with three methods, say: class Display a where displayBuilder :: a -> Builder default displayBuilder :: Show a => a -> Builder displayBuilder = fromString . show displayLazy :: a -> LT.Text displayLazy = toLazyText . displayBuilder display :: a -> Text display = toStrict . displayLazy Which comes with the big warning attached that if you define any of display/displayLazy, you also have to define displayBuilder. I guess alternatively we could also put the default signature on `display`, where `display` would then always be required. So as I understand it, the dowside is that a user can break the invariants between display/displayLazy/displayBuilder by accident. The up side is that it may be more efficient. I have no picture on how big the potential performance gain would be. If it is non-noticable for most practical cases, I would lean towards the simpler solution. An other direction could be to challenge whether we actually need the Builder version at all. I see that this is useful if we plan to apply `displayBuilder` recursively. If that use case is not prevalent, using Builder may also be less crucial (which again posses the question to me whether we really should build this on top of Text, or where we could use String instead which would at least technically allow this to be in base). Cheers, Simon