P2286 Formatting Ranges

[wg21bot]

P2286R0 Formatting Ranges (Barry Revzin)

[wg21bot]

P2286R1 Formatting Ranges (Barry Revzin)

[inbal2l]

Attaching a summary of the reviews (of R1: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2286r1.html)

1. Suggestion: use format specifiers to allow selection of printing mode:

   1. string like (does not include separators and braces, allow to print strings, as range of Integral)
   2. range, tule like (as proposed)

2. A request to explore the feasibility of changing the API to support forwarding references in section 3.4 (3.4 What about format specifiers?)
   Author: I've updated the paper - this isn't feasible. If you want to format move-only non-const-iterable ranges, then you'll have to either use the join() facility or wrap it in something like ref_view(). Move-only views by themselves are fine, it's only move-only + non-const-iterable that is the problem.

3. A question as to which types get considered strings:
   Author: fmt right now detects string-like on the presence of certain operations, so arbitrary ranges of char would not be considered strings. We could probably make this a variable template instead.

4. A question: Do you intend to support passing format specifiers for elements, for example formatting vector of dates?
   Author: Directly formatting ranges, no. With fmt::join, yes.

5. Discussion about formatting: Victor Zverovich (fmt lib) have added his input:

   1. I am in favor of making ranges formattable. Regarding the representation, I'd go with option 1 ([] for ranges and () for tuples) even though it's different from what {fmt} does for the same reason as Barry mentions in the paper: My preference for avoiding {} in the formatting is largely because it’s unlikely the results here can be used directly for copying and pasting directly into initialization anyway, so the priority is simply having visual distinction for the various cases, this representation is also more common in other languages.

   2. I wonder if it's worth exploring a separate representation for associative containers (map/unordered_map etc) as some languages like Python do?
      print({"a": 0, "b": 1}) // {'a': 0, 'b': 1}
      Author: (Editor's note: In essence - yes) We could make the {unordered_,flat_,}map and {unordered_,flat_}set formatters format like this specifically. I wouldn't want to do this for some arbitrary range of pairs, since we wouldn't really know if it's associative or not. In this case it's a clearer representation, we know they are associative containers.

   3. Regarding std::generator, can the issue be fixed by providing a formatter specialization for it?
      Author & Corentin: Once we get a generator const& There's nothing we can do. Maybe it can be supported if we had a facility such that format(str, a, b, c) evaluated as format(str, adjust(a), adjust(b), adjust(c)) before deduction happens, we might be able to take a generator and return it into a ref_view<generator> which could then be formatted normally.

Action Item: There's a lot of discussion regarding the integration with fmt, I suggest this paper will be scheduled for a Telecon.