Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

P2286 Formatting Ranges #977

Open
wg21bot opened this issue Jan 22, 2021 · 26 comments
Open

P2286 Formatting Ranges #977

wg21bot opened this issue Jan 22, 2021 · 26 comments
Labels
B3 - Addition C++23 IS LWG plenary-approved ranges tentatively-ready-for-plenary
Milestone

Comments

@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jan 22, 2021

P2286R0 Formatting Ranges (Barry Revzin)

@wg21bot wg21bot added the LEWG label Jan 22, 2021
@wg21bot wg21bot added this to the 2021-telecon milestone Jan 22, 2021
@brycelelbach brycelelbach added the ready-for-library-evolution-mailing-list-review label Jan 25, 2021
@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Feb 22, 2021

P2286R1 Formatting Ranges (Barry Revzin)

@cor3ntin cor3ntin added the scheduled-for-library-evolution label Feb 22, 2021
@brycelelbach brycelelbach added the ranges label Mar 22, 2021
@inbal2l
Copy link
Collaborator

@inbal2l inbal2l commented Apr 12, 2021

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.

@brycelelbach brycelelbach added ready-for-library-evolution-meeting-review needs-revision B3 - Addition scheduled-for-library-evolution and removed ready-for-library-evolution-mailing-list-review scheduled-for-library-evolution needs-revision labels May 17, 2021
@inbal2l inbal2l added SG9 and removed SG9 labels Jun 8, 2021
@inbal2l inbal2l added needs-revision ready-for-library-evolution-electronic-poll and removed ready-for-library-evolution-meeting-review scheduled-for-library-evolution ready-for-library-evolution-electronic-poll labels Jul 20, 2021
@inbal2l
Copy link
Collaborator

@inbal2l inbal2l commented Jul 20, 2021

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.

@brycelelbach brycelelbach added C++23 IS ready-for-library-evolution-meeting-review medium and removed needs-revision labels Aug 1, 2021
@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Aug 23, 2021

P2286R2 Formatting Ranges (Barry Revzin)

@brycelelbach brycelelbach added the needs-revision label Sep 2, 2021
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Sep 2, 2021

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.

@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Jan 22, 2022

P2286R6 Formatting Ranges (Barry Revzin)

@brycelelbach brycelelbach added scheduled-for-library-evolution C++23 and removed scheduled-for-library-evolution labels Feb 1, 2022
@cor3ntin
Copy link
Collaborator

@cor3ntin cor3ntin commented Feb 16, 2022

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.

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.

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

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

@cor3ntin cor3ntin added LWG and removed LEWG ready-for-library-evolution-electronic-poll scheduled-for-library-evolution labels Feb 16, 2022
@tahonermann
Copy link
Collaborator

@tahonermann tahonermann commented Feb 21, 2022

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 tahonermann added the needs-revision label Feb 21, 2022
@tahonermann
Copy link
Collaborator

@tahonermann tahonermann commented Feb 21, 2022

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

@brycelelbach brycelelbach added the lwg-pending label Feb 23, 2022
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Apr 6, 2022

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
Copy link
Member

@JeffGarland JeffGarland commented Apr 23, 2022

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

@JeffGarland JeffGarland added lwg-waiting and removed needs-revision lwg-pending medium labels Apr 23, 2022
@tahonermann
Copy link
Collaborator

@tahonermann tahonermann commented Apr 23, 2022

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

@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Apr 25, 2022

P2286R7 Formatting Ranges (Barry Revzin)

@tahonermann
Copy link
Collaborator

@tahonermann tahonermann commented May 5, 2022

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
Copy link
Collaborator

@tahonermann tahonermann commented May 13, 2022

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.

@tahonermann tahonermann removed the SG16 label May 13, 2022
@JeffGarland
Copy link
Member

@JeffGarland JeffGarland commented May 13, 2022

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

@JeffGarland JeffGarland added tentatively-ready-for-plenary and removed lwg-waiting labels May 13, 2022
@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented May 24, 2022

P2286R8 Formatting Ranges (Barry Revzin)

@cor3ntin cor3ntin added the plenary-approved label Jul 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B3 - Addition C++23 IS LWG plenary-approved ranges tentatively-ready-for-plenary
Projects
None yet
Development

No branches or pull requests

8 participants