search

cplusplus / papers

ISO/IEC JTC1 SC22 WG21 paper scheduling and management
621 stars 19 forks source link

P1715 Loosen restrictions on "_t" typedefs and "_v" values #481

Open wg21bot opened 5 years ago

wg21bot commented 5 years ago

P1715R0 Loosen restrictions on "_t" typedefs and "_v" values. (Jorg Brown)

tituswinters commented 5 years ago

I don't see this as being a bugfix for C++20 features - the only timeline/features discussed are C++14-era. Much as I'd love to see this happen, I don't think it meets the criteria for C++20-focus.

That said, it's also an LWG matter as far as I'm concerned. I'm dropping the LEWG tag, and recommend dropping the C++20 tag, but defer to Marshall.

jorgbrown commented 5 years ago

The paper that was mailed, pre-Cologne, is http://wg21.link/p1715r0 The reflectors reported a problem with that version, regarding function template argument deduction. This is corrected in http://wiki.edg.com/pub/Wg21cologne2019/LibraryWorkingGroup/D1715r1.html

mclow commented 4 years ago

This was not adopted for C++20. Removing the "C++20" label.

brycelelbach commented 1 year ago

2022-11-07 10:00 to 11:30 UTC-10 Kona Library Evolution Meeting

P1715R0: Loosen restrictions on "_t" typedefs and "_v" values

2022-11-07 10:00 to 11:30 UTC-10 Kona Library Evolution Minutes

Champion: Corentin Jabot

Chair: Fabio Fracassi & Billy Baker

Minute Taker: Steve Downey

Key Insights:

Summary

We feel this paper has some merits, but there was also some skepticism. Potential ABI and API inconsistencies have to be carefully surveyed.

Since this paper does not prescribe the changes but only gives implementors more freedom for better QoI.

Next Steps

Champion will provide an updated revision, which we will review.

brycelelbach commented 1 year ago

Why is this listed for C++23? The world wonders.

brycelelbach commented 1 year ago

Ah, this was listed for C++23 because we have an NB comment for it, FR-017-016 https://github.com/cplusplus/nbballot/issues/419

jorgbrown commented 1 year ago

New version addresses comments more specifically, corrects naming to be "P" rather than "D". => https://isocpp.org/files/papers/P1715R1.html

brycelelbach commented 1 year ago

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:

__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) + 14 (remote)

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

JeffGarland commented 1 year ago

@brycelelbach @billy-baker

I think there's something off in the notes here -- looks like copy-pasta w.r.t the 23/26 votes -- same poll two different outcomes?

brycelelbach commented 1 year ago

No, the polls are right. We took it once then learned new information afterwards.

jorgbrown commented 1 year ago

We took a vote and it fell extremely close to the consensus/no consensus line. And then we took a break for 15 minutes, after which Bryce resumed discussions after pointing out that, if not for the neutral votes, we would have consensus. After a short additional discussion, we re-voted, which did indeed reduce the number of neutral votes. Unfortunately for P1715, it wasn't enough, and the paper once again narrowly missed getting consensus.

Re: getting new information... I don't remember who it was who thought I was wrong about std::remove_cvref_t, but they were correct and I was indeed wrong... my opinion was partly based on clang & libc++, but in this case, libstdc++ has a much better implementation of std::remove_cvref_t, if by better you mean "smaller AST". See https://godbolt.org/z/aoGorjzWY

The real problem was that I was misremembering the problem from four years ago. It's not that remove_cvref must be implemented in terms of remove_reference and remove_cv.... it's that remove_reference_t and remove_cv_t and remove_cvref_t must each involve the instantiation of a different class. Whereas with the added flexibility of P1715, these could each involve the instantiation of the same shared class.

See https://godbolt.org/z/PEc51Tc1K for a rough sketch of how this would work, and how much AST size it saves, when compared to the base libc++. And I'll look into what libstdc++ is doing now, that saves so much AST space...

-- Jorg

On Mon, Feb 6, 2023 at 9:55 PM Jeff Garland @.***> wrote:

@brycelelbach https://github.com/brycelelbach @billy-baker https://github.com/billy-baker

I think there's something off in the notes here -- looks like copy-pasta w.r.t the 23/26 votes -- same poll two different outcomes?

— Reply to this email directly, view it on GitHub https://github.com/cplusplus/papers/issues/481#issuecomment-1420239003, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWUY2TAJ5XO7SAIEJZWWA3WWHPWJANCNFSM4H2ZZXUQ . You are receiving this because you commented.Message ID: @.***>