Title
Too many paper bump __cpp_lib_ranges
Status
new
Section
[version.syn]
Submitter
Jiang An

Created on 2023-05-03.00:00:00 last changed 3 months ago

Messages

Date: 2024-07-27.10:42:59

Proposed resolution:

This wording is relative to N4986.

  1. Modify [version.syn] as indicated:

    [Drafting notes:

    • It is proposed to restore __cpp_lib_ranges to the value denoting P2494R2.

    • __cpp_lib_ranges_accessors will cover P2602R2.

    • __cpp_lib_ranges_indirect_invocation will cover P2609R3 and P2997R1.

    • None of P2602R2, P2609R3, and P2997R1 really affected utilities in <functional>, so these two proposed macros are not required to be also in <functional>.

    • Proposed macros are freestanding because utilities changed by these papers are all freestanding now.

    ]

    […]
    #define __cpp_lib_ranges                            202406L202207L
      // also in <algorithm>, <functional>, <iterator>, <memory>, <ranges>
    #define __cpp_lib_ranges_accessors                  202211L
      // freestanding, also in <algorithm>, <iterator>, <memory>, <ranges>
    […]
    #define __cpp_lib_ranges_generate_random            202403L // also in <random>
    #define __cpp_lib_ranges_indirect_invocation        202406L
      // freestanding, also in <algorithm>, <iterator>, <memory>, <ranges>
    #define __cpp_lib_ranges_iota                       202202L // also in <numeric>
    […]
    
Date: 2024-07-15.00:00:00

[ 2024-07-24; Jiang An comments and provides improved wording ]

All utilities changed by P2602R2, P2609R3, and P2997R1 are now freestanding, so these proposed macros should also be freestanding.

Date: 2023-05-15.00:00:00

[ 2023-05-24; Reflector poll ]

Set priority to 3 after reflector poll.

"Needs a more descriptive name than mechanism."

This wording is relative to N4944.

  1. Modify [version.syn] as indicated:

    [Drafting note: It is proposed to restore __cpp_lib_ranges to the value denoting P2494R2.]

    […]
    #define __cpp_lib_ranges                            202302L202207L
    […]
    #define __cpp_lib_ranges_join_with                  202202L // also in <ranges>
    #define __cpp_lib_ranges_mechanism                  202302L
      // also in <algorithm>, <functional>, <iterator>, <memory>, <ranges>
    #define __cpp_lib_ranges_repeat                     202207L // also in <ranges>
    […]
    
Date: 2023-05-03.00:00:00

Currently MSVC STL implements P2602R2 and P2609R3 in C++20 mode as if they were defect reports. However, since P2387R3 and P2494R2, which are possibly considered pure functionality extensions in C++23, also bump __cpp_lib_ranges, it's impossible to detect the status of P2602R2 and P2609R3 in C++20 mode (see the discussion in MSVC STL repo).

This may be a non-defect as P2602R2 and P2609R3 are not officially DRs. However, if these papers (including upcoming P2538R1) are expected to be implemented in C++20 modes, it seems better to establish another feature-test macro (e.g., __cpp_lib_ranges_mechanism) for them.

History
Date User Action Args
2024-07-27 10:42:59adminsetmessages: + msg14271
2023-05-24 14:33:00adminsetmessages: + msg13578
2023-05-06 16:13:35adminsetmessages: + msg13544
2023-05-03 00:00:00admincreate