Whither split base?

[Herbert Valerio Riedel]

On 2018-10-30 at 08:04:59 -0400, Andrew Martin wrote:
> Here's an idea for this I had last night. It's narrowly scoped, but I think
> it moves us a tiny bit in the right direction. We could move Text.Printf
> out of base and into its own library. This doesn't really belong in base.
> The interface it provides it somewhat opinionated, and it's not even
> type-safe. The new library could be named `printf` and could live under the
> haskell github organization. Any thoughts for or against?

Ok, but what does this effectively achieve?

Text.Printf is an API that has been extremely stable and doesn't
significant evolve anymore; I don't think it has contributed to major
ver bumps in recent times, nor is it likely to. So I don't see much of a
compelling benefit in doing so. The effect I'd expect if we do this is
that `Text.Printf` will be reached for less (which some might argue to
be a desirable effect -- but you're effectively pushing this API to a
path of slow legacy death due to reduced discoverability, IMO), as the
convenience of using it is reduced by requiring adding and maintaining
an additional `build-depends` line to your package descriptions, as well
as having to deal with the subtly tricky business of handling the
migration path pre/post-split (c.f. the `network-bsd` split currently
being in progress).

Btw, a related extremely stable API in base I could think of which
people might argue doesn't belong into `base` either is maybe
`System.Console.GetOpt`; would you argue to split that off as well?