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

> 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

On Wed, Oct 12, 2016 at 1:53 AM David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> > On 12 Oct 2016, at 09:34, Chandler Carruth <chandlerc at
gmail.com> wrote:
> > 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.
>
Sorry, by heavyweight I meant more that everything in LLVM would end up
using it, and so any potential license incompatibility would be a serious
issue.

And "BSD / MIT-style licenses" specifically don't address a number
of the
issues raised in the licensing thread. I don't want to try to rehash it
here, but if we as a community think those issues are worth addressing,
that precludes depending on existing code carrying these licenses.

As a specific issue: if this code ends up transitively used in runtime
libraries, we would have binary attribution problems. So adding a
dependency on code under some other license is, IMO, problematic from a
very basic pragmatic perspective. It would move us back into having a weird
partition through the LLVM project of some code that could go into runtimes
but other code that could not go into runtimes. I don't want to go back to
that point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/838cc9c2/attachment.html>

On 12 Oct 2016, at 10:14, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> And "BSD / MIT-style licenses" specifically don't address a
number of the issues raised in the licensing thread. I don't want to try to
rehash it here, but if we as a community think those issues are worth
addressing, that precludes depending on existing code carrying these licenses.
> 
> As a specific issue: if this code ends up transitively used in runtime
libraries, we would have binary attribution problems. So adding a dependency on
code under some other license is, IMO, problematic from a very basic pragmatic
perspective. It would move us back into having a weird partition through the
LLVM project of some code that could go into runtimes but other code that could
not go into runtimes. I don't want to go back to that point.
2-clause BSD and MIT licenses (the relevant ones here) do address this.  They
are as permissive as the most permissive license used in LLVM (and far more
permissive than the proposed new license) and carry no binary attribution
clauses.

David