Created on 2023-05-03.00:00:00 last changed 11 months ago
Proposed resolution:
This wording is relative to N4944.
Modify [version.syn] as indicated:
[Drafting note: It is proposed to restore __cpp_lib_ranges to the value denoting P2494R2.]
[…] #define __cpp_lib_ranges202302L202207L […] #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> […]
[ 2023-05-24; Reflector poll ]
Set priority to 3 after reflector poll.
"Needs a more descriptive name than mechanism."
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 |
2023-05-24 14:33:00 | admin | set | messages: + msg13578 |
2023-05-06 16:13:35 | admin | set | messages: + msg13544 |
2023-05-03 00:00:00 | admin | create |