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

Justin Bogner via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 7 14:47:21 PST 2016


James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> You might be able to hook up a template-specialization like mechanic to the
>> processing of %s (similar to my current approach), but it's not obvious how
>> you proceed from there to get custom format strings for individual types.
>> For example, a formatter which can print a TimeSpan in different units
>> depending on style options you pass in.  This is especially useful when
>> trying to print ranges where you often want to be able to specify a
>> different separator, or control the formatting of the underlying type.
>>  (e.g. it's not clear how you would elegantly format a range of integers in
>> hex using this style of approach).
>>
>
> It is entirely unclear to me that putting everything in a format string:
>   formatv("Here's a range: {0:$[ + ]@[x]}", range);
> is better than composing functions with usual function-call syntax, e.g.
> something like this:
>   format("Here's a range: %s", Join(range, " + ", Formatter("%x")));
>
> I think that's the meat of the disagreement: I'd prefer to just see a safe
> printf-replacement; something that's able to basically drop-in replace C
> printf, nothing super fancy. I don't see the justification for being able
> to specify everything you'd ever want to be able to do directly in a
> complex format string language.
>
> On the other hand, you see value in being able to specify the entirety of
> the output in the format string, and aren't concerned about the syntax
> being new and complicated.
>
> That said -- it doesn't appear that my point of view is widely held, and
> that's fine -- this is a matter of opinion, not right or wrong. So,
> continue on. :)

FWIW, I'm also not entirely sold that we need a complex formatting
language here. The printf modifiers are easy to remember and are good
enough 90% of the time, whereas with something like this I feel like I'd
need to look up the syntax every time I used it.

Like James though, I'm fine with conceding to the majority on this one.


More information about the llvm-dev mailing list