-
Notifications
You must be signed in to change notification settings - Fork 4
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
FR-017-016 21.3 [type.traits] Allow efficient implementation of std::conditional_t
#419
Comments
std::conditional_t
std::conditional_t
The proposed resolution is to adopt P1715 cplusplus/papers#481 |
2023-02-06 13:00 to 15:15 Issaquah Library Evolution MeetingP1715R1: Loosen restrictions on 2023-02-06 13:00 to 15:15 UTC-8 Issaquah Library Evolution Minutes Champion: Jorg Brown (IP) Chair: Bryce Adelstein Lelbach (IP) & Billy Baker (IP) Minute Taker: Robert Leahy (IP) Start: 2023-02-06 14:46 UTC-8 Does this paper have:
POLL: Send P1715R1 (Loosen restrictions on
Attendance: 23 (in person) + 14 (remote) # of Authors: 1 Author Position: SF Outcome: No consensus. Break: 15:16 Resume: 15:31 POLL: Send P1715R1 (Loosen restrictions on
Attendance: 25 (in person) # of Authors: 1 Author Position: SF Outcome: No consensus. End: 15:58 SummaryWe discussed this proposal to give implementations freedom to improve the compile time performance of the Some implementers said they'd be unable to use this freedom as it would break ABIs. Others said they hoped to use it in their unstable ABI modes. It is believed that some implementations may be able to make the change without breaking ABI. Also, new implementations could take advantage of the freedom. There was a desire to learn more about the performance implications of this change. An addition to the paper with benchmark results would be helpful. The proposed change could be source breaking in some cases. There was a general belief that the impact on real-world code would be small. More discussion and analysis of this in the paper may help. Since there was an NB comment requesting this for C++23, we discussed whether we should try to squeeze it in. Some felt that there was no great urgency, and that adding it at this late stage might be risky. Ultimately, we did not have consensus to pursue it for C++23. Next StepsRevise P1715R1 (Loosen restrictions on Reject C++23 National Body comment FR-017-016 as we have no consensus for change. |
Rejected. There was no consensus for a change. |
Please consider adopting P1715 which failed to be adopted for C++20, and C++23 and which has the potential of improving compile time significantly.
The text was updated successfully, but these errors were encountered: