P2216R0: std::format improvements

P2216R0: std::format improvements

2020-11-10 Library Evolution Telecon Minutes

Chair: Ben Craig

Champion: Victor Zverovich

Minute Taker: Inbal Levi

Start: 2020-11-10 12:10 US CST

Pros:

• Prevents common mistakes, improving safety
• Reduces code bloat

Cons:

• Source breaking change (no shipping implementations yet)
• ABI breaking change (no shipping implementations yet)
• Requires either new compiler support, or future core language features

End: 13:10

SUMMARY: This paper is currently two proposals in one. The first is to add compile time checking to std::format, similar to the warning mechanisms many implementations already have for printf-like facilities. The second part of the paper reduces code bloat. Both of these are breaking changes, but if wg21 gets the changes into the working draft soon enough, no users will be broken, as there aren't any shipping implementations right now.

LEWG spent a great deal of time discussing implementability concerns, as well as the trade-offs between IFNDR, ill-formed, and well-formed + QOI warnings.

POLL: We should promise more committee time to pursuing the compile time checking aspects of P2216R0, knowing that our time is scarce and this will leave less time for other work.

Attendance: 21

# of Authors: 1

Author Position: SF

Outcome: Consensus to pursue

POLL: We should promise more committee time to pursuing the code bloat aspects of P2216R0, knowing that our time is scarce and this will leave less time for other work.

Attendance: 21

# of Authors: 1

Author Position: SF

Outcome: Consensus to Pursue

Request to split the paper into parts

POLL: (direction) We are comfortable having std::format compile time check failures cause the program to be ill-formed, no diagnostic required.

Attendance: 23

# of Authors: 1

Author Position: N

Outcome: LEWG is not comfortable with IFNDR

Recommend looking at builtin constant implementation methods

POLL: (direction) LEWG would prefer std::format compile time check failures to cause the program to be ill-formed (diagnostic required).

Attendance: 23

# of Authors: 1

Author Position: SF

Outcome: LEWG prefers ill-formed

N: Difference between a wish and a educated guidance. Need more experience since we don't have the language facilities.

POLL: (direction) We are comfortable having std::format compile time checks rely on compiler extensions to be implementable.

Attendance: 23

# of Authors: 1

Author Position: SF

Outcome: LEWG is somewhat is uncomfortable with relying on compiler extensions for this facility

WA: It seems reasonable to be able to provide this checking facility in general

P2216R1 std::format improvements (Victor Zverovich)

Summary

We discussed compile time correctness checks for std::format format strings. Two options were presented and we went with the more conservative one. We discussed a technique to reduce the binary size of std::format_to by (partially) type-erasing the output-iterator.

The paper was well prepared and motivated, and the discussion re-affirmed the direction of the paper. Most of the discussion was about the feasibility of introducing these changes, as they are breaking the currently specified status quo. We felt that the changes are sufficiently useful to do this even if it is a breaking change. We would prefer to treat this as a defect, i.e. urge implementers to ship only the newer specification.

Outcome

We voted in two breaking changes (wrt C++20) in the design of format. We did this with the understanding that std::format is not yet shipping in any implementation, and the strong encouragement that implementors should prefer the newer design from the beginning to avoid inconsistency and churn for the users.

Polls

Poll: We prefer Option 2 (only string literals) over option 1 (all constexpr format str)

Attendance: 22

# of Authors: 1

Author Position: SA

Outcome: Stay with option 1

Poll: We want to adopt the binary size reduction presented in P2216r1 even if it is a breaking change against C++20.

Attendance: 23

# of Authors: 1

Author Position: SF

Outcome: Strong consensus for change.

Poll: We would prefer the binary size reduction change to be made as a DR against C++20

Attendance: 23

# of Authors: 1

Author Position: SF

Outcome: Strong consensus for DR

Poll: We would prefer the compile time checking change to be made as a DR against C++20

Attendance: 23

# of Authors: 1

Author Position: SF

Outcome: Strong consensus for DR

Poll: Pending a wording review from Tim Song we want the next revision of this paper to proceed to electronic balloting with priority B1 (focus).

Attendance: 19

# of Authors: 1

Author Position: SF

Outcome: Strong consensus, we want this paper to proceed.

Billy Baker pointed out that C++23 should include an Annex C entry calling out the difference from C++20. Please add that to the proposal.

Please add that to the proposal.

Will do.

P2216R2 std::format improvements (Victor Zverovich)

Tentatively planned for LWG review 2020-02-05

Reviewed and approved for c++23 with preference to apply changes backward to c++20. We will wait to put in plenary for final LEWG electronic poll completes -- so summer 2021.

poll: do we want to put P2216r3 into C++23 after the requested edits are reviewed by CC and JG (pending LEWG approval)?

https://wiki.edg.com/bin/view/Wg21telecons2021/P2216-20210205

P2216R3 std::format improvements (Victor Zverovich)

2021 Winter Library Evolution Polls

P2333: 2021 Winter Library Evolution Poll Outcomes

POLL 3: Send P2216R2 (std::format Improvements) to LWG for C++23, classified as an improvement of an existing feature (P0592R4 bucket 2 item).

Outcome: Strong consensus in favor.

Outcome

Send P2216R2 (std::format Improvements) to LWG for C++23, classified as an improvement of an existing feature (P0592R4 bucket 2 item).

@JeffGarland I marked this tentatively-ready-for-lwg, which I hope is the right status.

LWG has already completed work -- moving as ready for plenary.

Adding the c++20 label to indicate the desire for this to be applied to c++20 implementations

Adopted 2021-06.