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

[Zachary Turner via llvm-dev]

On Tue, Oct 11, 2016 at 11:29 PM Chandler Carruth <chandlerc at google.com>
wrote:

> I'm generally favorable on the core idea of having a type-safe and
> friendly format-string-like formatting utility. Somewhat minor comments
> below:
>
> On Tue, Oct 11, 2016 at 6:22 PM Zachary Turner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> The high level design of my library is borrowed heavily from C#.
>
>
> My only big hesitation here is that the substitution specifier seems
> heavily influenced by C#. I'd prefer to model this after a format string
> syntax folks are fairly familiar with. IMO, Python's is probably the best
> bet here and has had a lot of hammering on it over the years. So I'd
> suggest that the pattern syntax be mapped to be as similar to Python's as
> possible or at least built on top of it.
>
A lot of Python's substitution rules only make sense in the context of a
language with reflection.  For example, you can write "{0.x}".format(obj)
in python which means to print obj.x.  If you take all of that out of the
equation, Python and C#'s formatting syntax is honestly very similar.  They
both use curly brace delimeters, they both index by number, they both use a
: separator.

The biggest difference is that Python smashes ALL of the formatting info
into a single field (i.e. everything after the colon), whereas C# separates
this into two fields as follows:

{index[,align][:options]}

I prefer this approach because it draws a firm line between the
type-specific formatting (e.g. the options field) and universal formatting
(e.g. the alignment field).  I did find some potentially useful tidbits in
Python's specification that seem useful and which C# does not support
though.  For example, the ability to center a field, and the ability to
specify the padding character rather than always using spaces.  We could
possibly integrate some of those ideas.


>
> 1. os << format_string("Test");   // writes "test"
> 2. os << format_string("{0}", 7);  // writes "7"
>
>
> The "<< format_string(..." is ... really verbose for me. It also makes me
> strongly feel like this produces a string rather than a streamable entity.
>
> I'm not a huge fan of streaming, but if we want to go this route, I'd very
> much like to keep the syntax short and sweet. "format" is pretty great for
> that. If this is going to fully subsume its use cases, can we eventually
> get that to be the name?
>
> (While I don't like streaming, I'm not trying to fight that battle here...)
>
Just for the record, I'm not a fan either.  See my response to Sean Silva
for some alternatives.


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