[llvm-dev] RFC: General purpose type-safe formatting library (original) (raw)

Zachary Turner via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 12 08:53:46 PDT 2016

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 formathex/formathexnoprefix 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 <<_ _formatstring(...) << ...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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/46b77382/attachment.html>

More information about the llvm-dev mailing list