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

FR-017-016 21.3 [type.traits] Allow efficient implementation of std::conditional_t #419

Closed
wg21bot opened this issue Oct 23, 2022 · 3 comments
Labels
has-paper LEWG Library Evolution rejected No consensus for a change.
Milestone

Comments

@wg21bot
Copy link
Collaborator

wg21bot commented Oct 23, 2022

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.

@wg21bot wg21bot added the LEWG Library Evolution label Oct 23, 2022
@wg21bot wg21bot added this to the CD C++23 milestone Oct 23, 2022
@jensmaurer jensmaurer changed the title FR 21.3 [type.traits] Allow efficient implementation of std::conditional_t FR-017-016 21.3 [type.traits] Allow efficient implementation of std::conditional_t Nov 3, 2022
@brycelelbach
Copy link

The proposed resolution is to adopt P1715 cplusplus/papers#481

@brycelelbach
Copy link

2023-02-06 13:00 to 15:15 Issaquah Library Evolution Meeting

P1715R1: Loosen restrictions on _t typedefs

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:

  • Examples?
    • Yes.
  • Field experience?
    • Some, but not of the entire proposal in a production Standard Library.
  • Performance considerations?
    • Not in the paper - such performance data should be included.
  • Discussion of prior art?
    • Yes.
  • Changes Library Evolution previously requested?
    • Yes.
  • Wording?
    • Yes.
  • Breaking changes?
    • Yes. The impact hasn't been sufficiently evaluated.
  • Feature test macro?
    • Not needed.
  • Freestanding?
    • N/A.

POLL: Send P1715R1 (Loosen restrictions on _t typedefs) to Library for C++23 as the resolution to C++23 National Body comment FR-017-016, classified as B2 - improvement.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
6 10 5 4 1

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 _t typedefs) to Library for C++23 as the resolution to C++23 National Body comment FR-017-016, classified as B2 - improvement.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
6 11 2 7 2

Attendance: 25 (in person)

# of Authors: 1

Author Position: SF

Outcome: No consensus.

End: 15:58

Summary

We discussed this proposal to give implementations freedom to improve the compile time performance of the _t typedefs.

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 Steps

Revise P1715R1 (Loosen restrictions on _t typedefs) and return to Library Evolution for further design review for C++26.

Reject C++23 National Body comment FR-017-016 as we have no consensus for change.

@jensmaurer jensmaurer added the rejected No consensus for a change. label Feb 9, 2023
@jensmaurer
Copy link
Member

Rejected. There was no consensus for a change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has-paper LEWG Library Evolution rejected No consensus for a change.
Projects
None yet
Development

No branches or pull requests

3 participants