> > 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).