llvm dev - Oct 2016 - RFC: General purpose type-safe formatting library

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?

David

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>

> 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