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 · 13 comments
Open

P2286 Formatting Ranges #977

wg21bot opened this issue Jan 22, 2021 · 13 comments

Comments

@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jan 22, 2021

P2286R0 Formatting Ranges (Barry Revzin)

@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Feb 22, 2021

P2286R1 Formatting Ranges (Barry Revzin)

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

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

@wg21bot
Copy link
Collaborator Author

@wg21bot wg21bot commented Aug 23, 2021

P2286R2 Formatting Ranges (Barry Revzin)

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

@jensmaurer jensmaurer removed this from the 2021-telecon milestone Nov 12, 2021
@billy-baker
Copy link
Collaborator

@billy-baker billy-baker commented Nov 22, 2021

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

@wg21bot wg21bot commented Nov 26, 2021

P2286R3 Formatting Ranges (Barry Revzin)

@wg21bot wg21bot added this to the 2021-telecon milestone Nov 26, 2021
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Nov 29, 2021

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)

@cor3ntin cor3ntin removed the C++23 label Dec 8, 2021
@tahonermann
Copy link
Collaborator

@tahonermann tahonermann commented Dec 17, 2021

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

  • Poll 0: We recommend using universal character name escape sequences rather than
    numerical escape sequences for the debug representation of all non-printable characters.
    • Attendance: 12

      SF F N A SA
      6 2 2 0 0
    • Consensus in favor

  • Poll 1: We recommend using brace-delimited numerical escape sequences as described in
    P2290 "Delimited Escape Sequences" for 'debug' formatting of invalid codeunits
    (including lone surrogates).
    • Attendance: 12

      SF F N A SA
      4 4 1 1 0
    • Consensus in favor

    • A: Delimited hex escape sequences do not exist in C++ yet and are not used elsewhere;
      but since they will only appear in cases of invalid code units, not SA.

  • Poll 2: We recommend using brace-delimited universal character name escape sequences
    as described in P2290 "Delimited Escape Sequences" for 'debug' formatting of strings.
    • Attendance: 12

      SF F N A SA
      3 3 4 0 0
    • Consensus in favor

@tahonermann
Copy link
Collaborator

@tahonermann tahonermann commented Dec 17, 2021

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

  • Poll 2: Modify D2286R4 to address design feedback, and forward the published paper as revised to LEWG with a
    recommended ship vehicle of C++23.
    • Attendance: 10

      SF F N A SA
      3 3 2 0 1
    • Consensus.

    • N: Lack of wording.

    • SA: Lack of wording; concerned that there will be subtle issues that won't become apparent until wording
      is available.

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

@wg21bot wg21bot commented Dec 18, 2021

P2286R4 Formatting Ranges (Barry Revzin)

@inbal2l
Copy link
Collaborator

@inbal2l inbal2l commented Jan 4, 2022

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 Jan 18th 2022.

@inbal2l
Copy link
Collaborator

@inbal2l inbal2l commented Jan 12, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants