As discussed in #102, there is currently no way to use the Pretty typeclass in combination with annotations. In that issue, several alternatives were discussed, which were either backwards incompatible or otherwise potentially computationally expensive.
But the first issue also mentioned the "obvious" version of the Pretty typeclass. Namely:

class Pretty a ann where
    pretty :: a -> Doc ann

But changing the definition of the typeclass would be obviously backwards incompatible.
So I propose the following change:

Add a PrettyAnn typeclass

Add the following typeclass to the library

class PrettyAnn a ann where
    prettyAnn :: a -> Doc ann

together with the obvious instances for primitives, strings, text etc. Just like for Pretty right now.

I see the following benefits:

• Purely additive change, no problems with backwards incompatibility.
• "Simple" solution. Neither fancy types nor other typeclasses are involved. Only MultiParamTypeclasses.
• Performance characteristic is obvious: No implicit insertions of unAnnotate or similar functions which traverse the Doc.
• This is already a solution users implement downstream in their applications. Why not provide a canonical way how to do it?

And the following downsides:

• Increases API surface. Now there are two typeclasses for prettyprinting. The documentation could just explicitly state that the user should use Pretty for prettyprinting without annotations, and PrettyAnn for prettyprinting with annotations.
• Does not lead to the "ideal" solution, since the Pretty class is left as a historical wart, instead of being a special case of PrettyAnn a Void