P2216 std::format improvements

[wg21bot]

P2216R0 std::format improvements (Victor Zverovich)

[ben-craig]

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.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
6	6	3	0	0

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.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
3	8	6	0	0

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.

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

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
5	7	1	0	0

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.

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

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

[wg21bot]

P2216R1 std::format improvements (Victor Zverovich)

[FabioFracassi]

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)

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	3	0	7	2

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.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	8	0	0	0

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	6	3	0	0

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	7	1	0	0

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

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
9	5	0	0	0

Attendance: 19

# of Authors: 1

Author Position: SF

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