This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

3931. Too many paper bump __cpp_lib_ranges

Section: 17.3.2 [version.syn] Status: New Submitter: Jiang An Opened: 2023-05-03 Last modified: 2023-05-24

Priority: 3

View other active issues in [version.syn].

View all other issues in [version.syn].

View all issues with New status.

Discussion:

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.

[2023-05-24; Reflector poll]

Set priority to 3 after reflector poll.

"Needs a more descriptive name than mechanism."

Proposed resolution:

This wording is relative to N4944.

  1. Modify 17.3.2 [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>
    […]