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?