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

[Chandler Carruth via llvm-dev]

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.

I understand that LLVM's refusal to depend on and re-use existing open
source code is frustrating, I'm actually rather frustrated as well at times
by the NIH-like pattern. But I think there are good reasons for LLVM to
eschew third party libraries in its core utilities, not the least of which
are the inherent licensing complications.

LLVM faces a somewhat unique challenge when it comes to licensing compared
to most other open source software: parts of LLVM are embedded into the
binaries we build. This makes finding a "compatibly licensed" existing
project .... unlikely. ;]

I don't want to spin off on a debate here about which license LLVM should
use or not use or what all it needs to say. We have a separate thread about
that. But one hope I have of *any* resolution ta that thread is that
perhaps more open source projects will use exactly the same license. If
they do, we might finally be able to have more reuse of existing open
source code.


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.

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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/463bb6ce/attachment.html>