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

[Zachary Turner via llvm-dev]

On Tue, Oct 11, 2016 at 11:15 PM Sean Silva <chisophugis at gmail.com> wrote:

> This is awesome. +1
>
> Copying a time-tested design like C#'s (and which also Python uses) seems
> like a really sound approach.
>
> Do you have any particular plans w.r.t. converting existing uses of the
> other formatting constructs? At the very least we can hopefully get rid of
> format_hex/format_hex_no_prefix since I don't think there are too many uses
> of those functions.
>
I can certainly try, although when I did a quick grep I found 1,637 uses of
llvm::format().  It's something we can work towards slowly, but I don't
imagine I have the capacity to convert all of these by myself.  Getting rid
of format_hex() could be a worthy first step though.


>
> Also, Since the format string already can embed the surrounding literal
> strings, do you anticipate the use case where you would want to use `OS <<
> format_string(...) << ...something else...`?
> Would `print(OS, "....", ....)` make more sense?
>
Perhaps.  I would argue that the whole reason we use << in the first place
is *because* we don't have a real formatting function.  And when we do have
one -- assuming it's designed correctly -- streaming operators become
unnecessary / a thing of the past.  I can imagine a couple of different
syntaxes.

os.format(format_str, args...);   // format() is an instance method of
raw_ostream.
T format_string<T>(format_str, args...);  // returns a T  (e.g. a
std::string, or SmallString<N>)

T &formatf(T &t, format_str, args...);  // formats to the location
specified by T, which could be a stream, std::string, SmallString, etc.  In
practice this could be implemented by having the raw_ostream overload call
os.format(format_str, args); and having the other versions create a
raw_string_ostream or raw_svec_ostream and delegating to the stream version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/46b77382/attachment.html>