(original) (raw)

On Tue, Oct 11, 2016 at 11:15 PM Sean Silva <chisophugis@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(format\_str, args...); // returns a T (e.g. a std::string, or SmallString)

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.