You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Activity
ben-craig commentedon Nov 13, 2020
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:
Cons:
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
wg21bot commentedon Dec 27, 2020
P2216R1 std::format improvements (Victor Zverovich)
FabioFracassi commentedon Jan 12, 2021
Summary
We discussed compile time correctness checks for
std::formatformat strings. Two options were presented and we went with the more conservative one. We discussed a technique to reduce the binary size ofstd::format_toby (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::formatis 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.
24 remaining items
brycelelbach commentedon Mar 12, 2021
2021 Winter Library Evolution Polls
P2333: 2021 Winter Library Evolution Poll Outcomes
POLL 3: Send P2216R2 (
std::formatImprovements) 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::formatImprovements) to LWG for C++23, classified as an improvement of an existing feature (P0592R4 bucket 2 item).brycelelbach commentedon Mar 12, 2021
@JeffGarland I marked this tentatively-ready-for-lwg, which I hope is the right status.
JeffGarland commentedon Mar 13, 2021
LWG has already completed work -- moving as ready for plenary.
JeffGarland commentedon Apr 9, 2021
Adding the c++20 label to indicate the desire for this to be applied to c++20 implementations
wg21bot commentedon Oct 26, 2021
Adopted 2021-06.