[llvm-dev] RFC: General purpose type-safe formatting library

[David Chisnall via llvm-dev]

> On 12 Oct 2016, at 09:34, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> On Wed, Oct 12, 2016 at 1:23 AM David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> On 12 Oct 2016, at 07:29, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> >
> 
> > I'm generally favorable on the core idea of having a type-safe and friendly format-string-like formatting utility
> 
> 
> 
> I’m also generally in favour, but I wonder what the key motivations for designing our own, rather than importing something like FastFormat, fmtlib, or one of the other tried-and-tested C++ typesafe I/O libraries is.  Has someone done an analysis of why these designs are a bad fit for LLVM, or are we just reinventing the wheel because we feel like it?
> 
> (this keeps coming up in various contexts, so a somewhat longer/in-depth post than I originally intended. If folks want to discuss this further should probably fork a new thread)
> 
> Given the tendency of utilities like this to become used pervasively in the project, it would seem a fairly heavy weight dependency to grow.

A reimplementation is likely to be no less complex than any of the originals.  Both fmtlib and FastFormat are under BSD / MIT-style licenses and are both small enough that it would be possible to embed copies of either in the LLVM tree if eliminating a dependency were desired.

Even if the implementation is not useable, adopting similar interfaces to an existing C++ solution is likely to be more friendly to C++ developers than designing something based on C# or Python.

> Either way, rolling our own has some advantages: LLVM may be able to make simplifying tradeoffs other libraries cannot realistically make due to narrower use cases and needs.

If that is the case, I would be totally in favour of rolling our own, but it seems that rolling our own was a decision made before investigating the alternatives.

> Provided we're only talking about very low level utilities like this, the cost doesn't seem terribly high to rolling our own, so I'm generally comfortable doing it.
> 
> Doesn't mean we shouldn't look at all the existing ones and learn everything we can from them.

Completely agreed.

David