P2286R1 Formatting Ranges (Barry Revzin)

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.

2021-07-20 Library Evolution Telecon

D2286R2: Formatting Ranges

2021-07-20 Library Evolution Telecon Minutes

Chair: Inbal Levi

Champion: Barry Revzin

Minute Taker: Ben Craig

Start Discussion: 2021-07-20 10:10 Pacific

End Discussion: 2021-07-20 11:05 Pacific

Summary

During the discussion, three major topics came up:

1. std::format takes arguments by reference to const, this will limit the usability as specified in section: 3.5 How to support those views which are not const-iterable?.
   Victor (implementer of std::fmt, on which std::format is based on) have suggested changing this in the past and got weak objections.

   Action Item: Send a concrete suggestion to DR change in LEWG's mailing list. If feedback is positive, we'll vote on the
   change, and the change should be ported to P2286 accordingly.

2. There was a proposed alternative for the printed format for map-like associative containers by Victor:

   std::map<std::string, char> m = {{"hello", 'h'}, {"world", 'w'}};
   
   Would be printed as:
   {“hello”: ‘h’, “world”: ‘w’}

   Action Item: We took a poll, which approved this is the preferred way to print map-like associative containers.

3. There was a discussion regarding the concept formattable-impl proposed in the paper. The concept was phrased to be less constraining as possible, considering std::format requirements from a formattable-impl. The concept was phrased with the help of Tim.

   Action Item: Author was requested to have additional pair of eyes to overview the concept specification.

Polls

We took the following polls:

POLL: Investigate a change for all map-like associative containers format in D2286R2 into:

std::map<std::string, char> m = {{"hello", 'h'}, {"world", 'w'}};

Would be printed as:
{“hello”: ‘h’, “world”: ‘w’}

Attendance: 18

# of Authors: 1

Author's Position: N

Outcome: Weak consensus in favor

POLL: Forward next revision of D2286R2 (with the suggested changes below) to LEWG’s mailing list, and then forward to electronic polling, assuming good feedback from the mailing list.

Suggested changes:

1. Investigate a change in std::format to take arguments by forwarding reference instead of reference to const
2. Investigate a change in all map-like associative containers format

Attendance: 18

# of Authors: 1

Author Position: SF

Outcome: Consensus in favor

SA: I can’t forward something that is not finalized

Outcome

The author (in cooperation with the author of fmt) will post a question regarding the investigation of std::format to take arguments by forwarding reference instead of reference to const in LEWG's mailing.
Then he will change the paper accordingly, including the other recommendation specified in the second poll and will post the finalized version on the mailing list. Please also add a feature test macro.

If no strong objection will be made, the new revision (P2286R2) will be forwarded to electronic polling.

P2286R2 Formatting Ranges (Barry Revzin)

2021-08-31 Library Evolution Telecon

D2286R3: Formatting Ranges

2021-08-31 Library Evolution Telecon Minutes

Chair: Inbal Levi

Champion: Barry Revzin

Minute Taker: Ben Craig

Summary

The paper generally got good support. Few remarks:

1. The debug formatting solution presented in D2286R3 was generally supported. (Tomasz had few comments, and sent his feedback on the mail thread: "[isocpp-lib-ext] P2286 (formatting ranges): Feedback")

2. The specific syntax described - {:?} was also supported.

3. The author was requested to address user-defined formatting in general and user-defined debug formatting in particular.

4. The paper will come back to LEWG when ready.

POLL: We like the debug formatting solution presented in D2286R3 (Formatting Ranges).

Attendance: 19

# of Authors: 1

Author Position: WF

Outcome: Consensus in favor

WA: Covering filesystem path and alternative for format_as_map mentioned in the paper. Discuss quoted strings. Addressing those will change my vote.

POLL: We want {:?} to do quoting escaping of the types as presented in D2286R3 (Formatting Ranges).

Attendance: 19

# of Authors: 1

Author Position: N

Outcome: Consensus in favor

Outcome

The author will address the issues brought up, including with the "debug" facility, and present the next revision to LEWG when available.

2022-01-18 Library Evolution Telecon

P2286R5: Formatting Ranges

2022-01-18 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Barry Revzin

Minute Taker: Inbal Levi

Start: 2022-01-18 11:20 Eastern

Does this proposal have:

• Examples?
  • Yes.
• Implementation experience?
  • Yes, in fmt.
• Usage experience?
  • Yes, in fmt.
• Deployment experience?
  • Yes, in fmt.
• Performance considerations?
  • Yes.
• Discussion of prior art?
  • Yes, in fmt.
• Changes Library Evolution previously requested?
  • Yes, scope was reduced.
• Wording?
  • Yes.
• Feature test macro?
  • No.

Should specializations of formatter for ranges inherit from range_formatter?

Is the intent that you can pass a vector to any range formatter?
Answer: No.

POLL: Standard specializations of formatter for ranges, tuples, and pairs should not be required to store separators and brackets.

Attendance: 24

# of Authors: 1

Author Position: N

Outcome: No consensus.

POLL: Modify P2286R5 (Formatting Ranges) as described below and then send the revised paper to LWG for C++23 classified as an addition (priority B3), to be confirmed with a Library Evolution electronic poll.

• formatter<R>::format for ranges should take either an R& or an
  R const&, specifically, not a template.
• Add a feature test macro.

Attendance: 22

# of Authors: 1

Author Position: 1xSF

Outcome: Unanimous consensus in favor.

Submit the slides as a P document.

End: 12:09

Outcome

Modify P2286R5 (Formatting Ranges) as described below and then send the revised paper to LWG for C++23 classified as an addition (priority B3), to be confirmed with a Library Evolution electronic poll.

• formatter<R>::format for ranges should take either an R& or an
  R const&, specifically, not a template.
• Add a feature test macro.

SG16 discussed P2286R6 during its January 26th, 2022 telecon. The focus of the discussion was to review wording with the goal of identifying new concerns. No new concerns were identified and no new polls were taken. Wording feedback and suggestions were sent to the author.

The design and wording remains under specified for non-Unicode scenarios as noted in the meeting summary linked above. For that reason, I'm retaining the SG16 label pending a new revision. I anticipate that additional review or implementation experience will be needed to better inform behavior for non-Unicode scenarios.

I added the needs-revision label to address SG16 wording feedback and the need to better address non-Unicode scenarios.

2022-01 Library Evolution Electronic Poll Outcomes

Send [P2286R6] (Formatting Ranges) to Library Working Group for C++23, classified as an addition ([P0592R4] bucket 3 item)

Consensus in favor.

LWG reviewed and approved wording on 2022-04-22 for c++23 with recheck after SG16 tweaks wording for non-unicode implementations.

https://wiki.edg.com/bin/view/Wg21telecons2022/P2286-20220422

poll: put P2286r7 into C++23?

SG16 will review updates and confirm direction during its 2022-04-27 telecon.

P2286R7 Formatting Ranges (Barry Revzin)

SG16 reviewed the current draft of P2286R7 during its 2022-04-27 telecon.

@JeffGarland, we are still working through some wording updates, but intend to finalize those by/during our 2022-05-11 telecon next week.

SG16 reviewed a draft of P2286R8 during its 2022-05-11 telecon. This draft addresses the concerns SG16 previously had with respect to non-Unicode scenarios being under specified. All concerns previously raised by SG16 have now been addressed.

The following poll was taken:

• Poll: Forward D2286R8 to LWG with 2.3.1 and associated table revised to substitute "character" for "UCS scalar value" as discussed for inclusion in C++23
  • Attendance 8
  • No objection to unanimous consent.

Removing the SG16 label; this paper is now fully in LWG's capable hands.

LWG re-reviewed on 2022-05-13 and asked for one small change from a Note to Recommended Practice. The update was reviewed live in the meeting and LWG re-affirmed support for C++23.

https://wiki.edg.com/bin/view/Wg21telecons2022/P2286-20220513

poll: put p2286r8 into C++23

P2286R8 Formatting Ranges (Barry Revzin)

This has been applied.