search

cplusplus / papers

ISO/IEC JTC1 SC22 WG21 paper scheduling and management
678 stars 18 forks source link

P2286 Formatting Ranges #977

Closed wg21bot closed 2 years ago

wg21bot commented 3 years ago

P2286R0 Formatting Ranges (Barry Revzin)

wg21bot commented 3 years ago

P2286R1 Formatting Ranges (Barry Revzin)

inbal2l commented 3 years ago

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/unorderedmap 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.

inbal2l commented 3 years ago

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’}
Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
3 6 3 2 0

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
Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
6 4 2 0 1

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.

wg21bot commented 3 years ago

P2286R2 Formatting Ranges (Barry Revzin)

brycelelbach commented 3 years ago

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).

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
3 5 4 1 0

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).

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
3 5 5 0 0

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.

billy-baker commented 3 years ago

2021-11-22 Library Evolution Telecon

2021-11-22 Library Evolution Telecon minutes

Chair: Billy Baker

Champion: Barry Revzin

Minute Taker: Inbal Levi

Summary:

The feature continues to receive support.

LEWG will need to review again.

Wording is still needed.

Outcome:

Based on discussions of basic character set versus unicode for delimiters, a review from SG16 (Text processing) is needed before additional review in Library Evolution.

wg21bot commented 3 years ago

P2286R3 Formatting Ranges (Barry Revzin)

brycelelbach commented 3 years ago

2021-11-22 Library Evolution Telecon

P2286R3: Formatting Ranges

2021-11-22 Library Evolution Telecon Minutes

Chair: Billy Baker

Champion: Barry Revzin

Minute Taker: Inbal Levi

No polls were taken, the paper needs additional discussion time (should also be reviewed by SG16).

Summary

TODO (@billy-baker)

Outcome

TODO (@billy-baker)

tahonermann commented 2 years ago

SG16 discussed P2286R3 during its 2021-12-01 telecon. The following polls were taken:

tahonermann commented 2 years ago

SG16 discussed a draft of P2286R4 during its 2021-12-15 telecon. The following polls were taken.

Though SG16 elected to approve the design, I'm going to retain the SG16 label for now due to intent to review wording, assuming availability, during the SG16 telecon scheduled for 2022-01-12.

wg21bot commented 2 years ago

P2286R4 Formatting Ranges (Barry Revzin)

inbal2l commented 2 years ago

Paper was discussed in LEWG on Jan 4th 2022 (Full Minutes)

2022-01-04 Library Evolution Telecon

P2286R4: Formatting Ranges

Chair: Inbal Levi

Champion: Barry Revzin

Minute Taker: Ben Craig

Summary

The comments suggests the addition is supported, but request for removal of the more complex facilities (especially the ones with no implementation experience in fmt).

POLL: LEWG would like to see a revision of P2286 without the d specifier

Strongly Favor Favor Neutral Against Strongly Against
4 7 5 5 0

Attendance: 26

# of Authors: 1

Author Position: WA

Outcome: Weak consensus in favor

Outcome

The addition was supported, but the majority of the attendees generally agreed the paper is covering a large scope, and should be reduced.

We'll see the updated revision on LEWG's meeting on 2022-01-18.

inbal2l commented 2 years ago

Was seen by SG9 (Ranges) on 2021-01-10 (Full Minutes).

Polls

None.

Summary

The scope of the paper was reduced as requested by LEWG. The question of diversion from "fmt" (not proposing "join") came up as well, author believe the proposed facility is more usable. Fixed wording was not reviewed at the meeting, author was advised to send the revision in SG9 / LEWG ML prior to the Jan 18th LEWG telecon.

P2286 (without user defined terminators) will continue to LEWG final review (and voting) on Jan 18th.

wg21bot commented 2 years ago

P2286R5 Formatting Ranges (Barry Revzin)

wg21bot commented 2 years ago

P2286R6 Formatting Ranges (Barry Revzin)

cor3ntin commented 2 years ago

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:

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
2 0 6 4 1

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
10 8 0 0 0

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.

tahonermann commented 2 years ago

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.

tahonermann commented 2 years ago

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

brycelelbach commented 2 years ago

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)

SF F N A SA
18 17 1 1 0

Consensus in favor.

JeffGarland commented 2 years ago

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?

F A N
12 0 1
tahonermann commented 2 years ago

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

wg21bot commented 2 years ago

P2286R7 Formatting Ranges (Barry Revzin)

tahonermann commented 2 years ago

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.

tahonermann commented 2 years ago

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:

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

JeffGarland commented 2 years ago

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

F A N
10 0 0
wg21bot commented 2 years ago

P2286R8 Formatting Ranges (Barry Revzin)

tkoeppe commented 2 years ago

This has been applied.