iso646.h: This suppression is no longer necessary. (Apparently
unrelated to LLVM-43531, fixed after Clang 9.)
xutility: This exceeded 120 columns. clang-format doesn't make it
unreadable, so we should just enable it.
In GH-425 I was forced to add a dead initialization for the _Count variable in _Sort_unchecked in order to comply with constexpr rules. Also, _Sort_unchecked had somewhat complex assignment-in-conditional-expressions going on. This change moves the code around such that the _Count variable is assigned once.
Also:
* Consistently test _ISORT_MAX with <= where possible, and make that an _INLINE_VAR constexpr variable.
* Remove _Count guards of 1 in front of _Insertion_sort_unchecked for consistency. I did performance testing and there was no measurable difference in keeping this check, and it's more code to reason about.
* Avoid needless casts of _ISORT_MAX given that it is now a constexpr constant.
* Implement fixes from D2091R0 "Issues with Range Access CPOs"
* Pre-existing: Correctly annotate implementations of outstanding `iter_move` LWG issues. LWG-3247 was not annotated, and LWG-3299 incorrectly annotated as LWG-3270 (the number had to be changed after submission).
* Remove the `initializer_list` poison pills for `ranges::begin`, `ranges::end`, `ranges::rbegin`, and `ranges::rend`. They were necessary only to prevent `initializer_list` from inadvertently opting-in to forwarding-range, and P1870R1 "forwarding-range<T> is too subtle" changed the opt-in.
* Always perform lookups for lvalues in `ranges::size`, `ranges::empty`, and `ranges::data` as is already the case for `ranges::begin`, `ranges::end`, `ranges::rbegin`, and `ranges::rend` post-P1870, which makes the CPOs easier to reason about and reduces template instantiations.
* Replace forwarding-reference poison pills with pairs of lvalue/const lvalue poison pills for `ranges::begin`, `ranges::end`, `ranges::rbegin`, `ranges::rend`, and `ranges::size`; the forwarding-reference versions are insufficiently poisonous and allow calls to plain `meow(auto&)`/`meow(const auto&)` templates.
* Only perform ADL probes in `ranges::begin`, `ranges::end`, `ranges::rbegin`, `ranges::rend`, and `ranges::size` for argument expressions of class or enumeration type.
* `ranges::begin`, `ranges::empty`, `ranges::data` accept (lvalue) arrays of unknown bound; `ranges::end` (and consequently `ranges::rbegin` and `ranges::rend`) rejects. Remove `range` constraint from `iterator_t`, so it works with (non-`range`) arrays of unknown bound. Add `range` constraints to the `range_meow_t` "compound" associated type traits, since they no longer get it from `iterator_t`.
* Hard error (with a pretty message) in `ranges::begin`, `ranges::end`, `ranges::rbegin`, or `ranges::rend` when the argument is an array whose element type is incomplete.
This bug is triggered when unqualified name lookup for `f` in `f(x)` finds only deleted function (template)s at template definition time, resulting in MSVC refusing to perform argument dependent lookup at template instantiation time. Unsurprisingly, all of the C++20 CPOs required workarounds.
* Implement constexpr algorithms.
Resolves GH-6 ( P0202R3 ), resolves GH-38 ( P0879R0 ), and drive-by fixes GH-414.
Everywhere: Add constexpr, _CONSTEXPR20, and _CONSTEXPR20_ICE to things.
skipped_tests.txt: Turn on all tests previously blocked by missing constexpr algorithms (and exchange and swap). Mark those algorithms that cannot be turned on that we have outstanding PRs for with their associated PRs.
yvals_core.h: Turn on feature test macros.
xutility:
* Move the _Ptr_cat family down to copy, and fix associated SHOUTY comments to indicate that this is really an implementation detail of copy, not something the rest of the standard library intends to use directly. Removed and clarified some of the comments as requested by Casey Carter.
* Extract _Copy_n_core which implements copy_n using only the core language (rather than memcpy-as-an-intrinsic). Note that we cannot use __builtin_memcpy or similar to avoid the is_constant_evaluated check here; builtin_memcpy only works in constexpr contexts when the inputs are of type char.
numeric: Refactor as suggested by GH-414.
* Attempt alternate fix of GH-414 suggested by Stephan.
* Stephan product code PR comments:
* _Swap_ranges_unchecked => _CONSTEXPR20
* _Idl_dist_add => _NODISCARD (and remove comments)
* is_permutation => _NODISCARD
* Add yvals_core.h comments.
* Delete unused _Copy_n_core and TRANSITION, DevCom-889321 comment.
* Put the comments in the right place and remove phantom braces.
* Optimize the is_permutation family and _Hash::operator== for multicontaniers slightly.
<xutility>
4660: _Find_pr is a helper for is_permutation, so move it down to that area.
4684: The SHOUTY banners were attached to functions which were implmentation details of is_permutation, so I fixed them up to say is_permutation and removed the banners for helper functions.
4711: Use if constexpr to avoid a tag dispatch call for _Trim_matching_suffixes. Optimizers will like this because they generally hate reference-to-pointer, and it also serves to workaround DevCom-883631 when this algorithm is constexprized.
4766: Indicate that we are trimming matching prefixes in this loop body, and break apart comment block that was incorrectly merged by clang-format.
4817: In the dual range forward version of the algorithm, calculate the distances concurrently to avoid wasting lots of time when the distances vary by a lot. For example, is_permutation( a forward range of length 1, a forward range of length 1'000'000 ) used to do the million increments, now it stops at 1 increment.
4862: In the dual range random-access version, avoid recalculating _Last2 when it has already been supplied to us.
<xhash>
1404: Move down construction of _Bucket_hi in _Equal_range to before the first loop body using it.
1918: Added a new function to calculate equality for unordered multicontainers. We loop over the elements in the left container, find corresponding ranges in the right container, trim prefixes, then dispatch to is_permutation's helper _Check_match_counts.
Improvements over the old implementation:
* For standard containers, we no longer need to hash any elements from the left container; we know that we've found the "run" of equivalent elements because we *started* with an element in that container. We also never go "backwards" or multiply enumerate _Left (even for !_Standard), which improves cache use when the container becomes large.
* Just like the dual range is_permutation improvement above, when the equal_ranges of the containers are of wildly varying lengths, this will stop on the shorter of the lengths.
* We avoid the 3-arg is_permutation doing a linear time operation to discover _Last2 that we already had calculated in determining _Right's equal_range.
The function _Multi_equal_check_equal_range tests one equal_range from the left container against the corresponding equal_range from the right container, while _Multi_equal invokes _Multi_equal_check_equal_range for each equal_range.
Performance results:
```
Benchmark Before (ns) After (ns) Percent Better
HashRandomUnequal<unordered_multimap>/1 18.7 11.7 59.83%
HashRandomUnequal<unordered_multimap>/10 137 97 41.24%
HashRandomUnequal<unordered_multimap>/100 1677 1141 46.98%
HashRandomUnequal<unordered_multimap>/512 10386 7036 47.61%
HashRandomUnequal<unordered_multimap>/4096 173807 119391 45.58%
HashRandomUnequal<unordered_multimap>/32768 2898405 1529710 89.47%
HashRandomUnequal<unordered_multimap>/100000 27441112 18602792 47.51%
HashRandomUnequal<hash_multimap>/1 18.9 11.8 60.17%
HashRandomUnequal<hash_multimap>/10 138 101 36.63%
HashRandomUnequal<hash_multimap>/100 1613 1154 39.77%
HashRandomUnequal<hash_multimap>/512 10385 7178 44.68%
HashRandomUnequal<hash_multimap>/4096 171718 120115 42.96%
HashRandomUnequal<hash_multimap>/32768 3352231 1510245 121.97%
HashRandomUnequal<hash_multimap>/100000 26532471 19209741 38.12%
HashRandomEqual<unordered_multimap>/1 16 9.4 70.21%
HashRandomEqual<unordered_multimap>/10 126 89.2 41.26%
HashRandomEqual<unordered_multimap>/100 1644 1133 45.10%
HashRandomEqual<unordered_multimap>/512 10532 7183 46.62%
HashRandomEqual<unordered_multimap>/4096 174580 120029 45.45%
HashRandomEqual<unordered_multimap>/32768 3031653 1455416 108.30%
HashRandomEqual<unordered_multimap>/100000 26100504 19240571 35.65%
HashRandomEqual<hash_multimap>/1 15.9 9.38 69.51%
HashRandomEqual<hash_multimap>/10 123 94.1 30.71%
HashRandomEqual<hash_multimap>/100 1645 1151 42.92%
HashRandomEqual<hash_multimap>/512 10177 7144 42.46%
HashRandomEqual<hash_multimap>/4096 172994 121381 42.52%
HashRandomEqual<hash_multimap>/32768 3045242 1966513 54.85%
HashRandomEqual<hash_multimap>/100000 26013781 22025482 18.11%
HashUnequalDifferingBuckets<unordered_multimap>/2 5.87 3.41 72.14%
HashUnequalDifferingBuckets<unordered_multimap>/10 12 3.39 253.98%
HashUnequalDifferingBuckets<unordered_multimap>/100 106 3.41 3008.50%
HashUnequalDifferingBuckets<unordered_multimap>/512 691 3.46 19871.10%
HashUnequalDifferingBuckets<unordered_multimap>/4096 6965 3.47 200620.46%
HashUnequalDifferingBuckets<unordered_multimap>/32768 91451 3.46 2642992.49%
HashUnequalDifferingBuckets<unordered_multimap>/100000 290430 3.52 8250752.27%
HashUnequalDifferingBuckets<hash_multimap>/2 5.97 3.4 75.59%
HashUnequalDifferingBuckets<hash_multimap>/10 11.8 3.54 233.33%
HashUnequalDifferingBuckets<hash_multimap>/100 105 3.54 2866.10%
HashUnequalDifferingBuckets<hash_multimap>/512 763 3.46 21952.02%
HashUnequalDifferingBuckets<hash_multimap>/4096 6862 3.4 201723.53%
HashUnequalDifferingBuckets<hash_multimap>/32768 94583 3.4 2781752.94%
HashUnequalDifferingBuckets<hash_multimap>/100000 287996 3.43 8396284.84%
```
Benchmark code:
```
#undef NDEBUG
#define _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS
#include <assert.h>
#include <benchmark/benchmark.h>
#include <hash_map>
#include <random>
#include <stddef.h>
#include <unordered_map>
#include <utility>
#include <vector>
using namespace std;
template <template <class...> class MapType> void HashRandomUnequal(benchmark::State &state) {
std::minstd_rand rng(std::random_device{}());
const auto range0 = static_cast<ptrdiff_t>(state.range(0));
vector<pair<unsigned, unsigned>> testData;
testData.resize(range0 * 5);
const auto dataEnd = testData.begin() + range0;
std::generate(testData.begin(), dataEnd, [&]() { return pair<unsigned, unsigned>{rng(), 0u}; });
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd, std::copy(testData.begin(), dataEnd, dataEnd))));
std::unordered_multimap<unsigned, unsigned> a(testData.begin(), testData.end());
testData.clear();
std::unordered_multimap<unsigned, unsigned> b = a;
next(b.begin(), b.size() - 1)->second = 1u;
for (auto &&_ : state) {
(void)_;
assert(a != b);
}
}
BENCHMARK_TEMPLATE1(HashRandomUnequal, unordered_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
BENCHMARK_TEMPLATE1(HashRandomUnequal, hash_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
template <template <class...> class MapType> void HashRandomEqual(benchmark::State &state) {
std::minstd_rand rng(std::random_device{}());
const auto range0 = static_cast<ptrdiff_t>(state.range(0));
vector<pair<unsigned, unsigned>> testData;
testData.resize(range0 * 5);
const auto dataEnd = testData.begin() + range0;
std::generate(testData.begin(), dataEnd, [&]() { return pair<unsigned, unsigned>{rng(), 0}; });
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd,
std::copy(testData.begin(), dataEnd, std::copy(testData.begin(), dataEnd, dataEnd))));
std::unordered_multimap<unsigned, unsigned> a(testData.begin(), testData.end());
testData.clear();
std::unordered_multimap<unsigned, unsigned> b = a;
for (auto &&_ : state) {
(void)_;
assert(a == b);
}
}
BENCHMARK_TEMPLATE1(HashRandomEqual, unordered_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
BENCHMARK_TEMPLATE1(HashRandomEqual, hash_multimap)->Arg(1)->Arg(10)->Range(100, 100'000);
template <template <class...> class MapType> void HashUnequalDifferingBuckets(benchmark::State &state) {
std::unordered_multimap<unsigned, unsigned> a;
std::unordered_multimap<unsigned, unsigned> b;
const auto range0 = static_cast<ptrdiff_t>(state.range(0));
for (ptrdiff_t idx = 0; idx < range0; ++idx) {
a.emplace(0, 1);
b.emplace(1, 0);
}
a.emplace(1, 0);
b.emplace(0, 1);
for (auto &&_ : state) {
(void)_;
assert(a != b);
}
}
BENCHMARK_TEMPLATE1(HashUnequalDifferingBuckets, unordered_multimap)->Arg(2)->Arg(10)->Range(100, 100'000);
BENCHMARK_TEMPLATE1(HashUnequalDifferingBuckets, hash_multimap)->Arg(2)->Arg(10)->Range(100, 100'000);
BENCHMARK_MAIN();
* Apply a bunch of code review comments from Casey.
* clang-format
* Apply @miscco's code deduplication idea for <xhash>.
* Fix code review comments from Stephan: comments and add DMIs.
This change is not a statement of support for the Intel C++ compiler by the STL, so much as an attempt to not break it gratuitously.
Fixes DevCom-744112.
* Implement P0357R3
* Update LLVM to get skip of libcxx\test\std\utilities\function.objects\refwrap\weak_result.pass.cpp, and exclude "// REQUIRES: c++98 || c++03 || c++11 || c++14 || c++17" as a 'magic comment'.
Co-authored-by: Billy O'Neal <billy.oneal@gmail.com>
Co-authored-by: Casey Carter <cartec69@gmail.com>
...which renames the feature-test macro `__cpp_lib_nothrow_convertible` to `__cpp_lib_is_nothrow_convertible`. We *just* added this feature-test macro which hasn't yet shipped, and therefore want to rename it quickly - ideally before customers notice it exists. LWG has tentatively approved this issue resolution.
This calls `abort()` as there's no need to invoke the terminate handler.
(This is a virtual function, so eliminating it entirely would risk ODR
violations leading to crashes. It's much safer to provide a definition
that can't be called.)
Additionally, fix `<xlocale>` to qualify `_CSTD abort()`.
While we must continue to support `msvcp140.dll` running on Windows XP,
we don't need to support compiling our headers with the (removed)
`v140_xp` toolset and its corresponding old Windows SDK. Accordingly,
we can unconditionally define `shared_mutex`. (This is a C++17 feature,
but it was implemented before Standard modes, so it's not guarded by
`_HAS_CXX17`.)
Currently, we're building the STL in both our Microsoft-internal MSVC
repo and in GitHub, as we work on the migration. The MSVC repo uses a
checked-in compiler (the "toolset") to build the STL and the compiler
itself. Earlier, the checked-in toolset identified itself as
19.25.28318.97 but lacked support for `is_constant_evaluated`, so we
needed to detect that exact version number. Now, the toolset has been
updated, so this workaround is no longer necessary.
When VS 2019 16.5 Preview 2 is available in the future, we'll begin
requiring it to build the GitHub sources, at which point we'll be able
to unconditionally define `__cpp_lib_is_constant_evaluated`.
* Avoid burning unused stack space for a T in _List_node_insert_op. Resolves#973579 and GH-365.
* Change forward_list to follow a similar pattern for consistency.
* First round of code review feedback.
Permanently work around DevCom-848104 by simplifying hash_meow::value_type. This is what unordered_meow::value_type already does, which is why that can already use int = 0 SFINAE.
* Fix#272: `<future>: promise<_Ty&>::set_value(_Ty& _Val)` should use `_STD addressof(_Val)`
* Fix#344: `<yvals_core.h>`: Update `_MSVC_STL_UPDATE` to December 2019
Hidden friends aren't hidden in C1XX's permissive mode, so let's use an alternate mechanism to make these operators truly ADL-only. (We want to avoid checking `weakly_incrementable` for every type that is compared via `==` or `!=` with a type associated with namespace `std`.)
Programs that include such specializations are ill-formed, since the Standard only specifies a partial specialization of `std::function<T>` for non-`noexcept` function types `T`. The current diagnostic:
```
error C2027: use of undefined type 'std::_Get_function_impl<_Fty>'
```
is not great.
Fixes DevCom-825902.
[This is a replay of Microsoft-internal MSVC-PR-215822.]
Implements iterator primitive operations `std::ranges::advance`, `std::ranges::next`, `std::ranges::prev`, and `std::ranges::distance`; as well as `std::default_sentinel` and `std::unreachable_sentinel`.
This change reworks the STL's iterator unwrapping machinery to enable unwrapping of C++20 move-only single-pass iterators (and `if constepxr`s all the things). Consequently, `_Iter_ref_t`, `_Iter_value_t`, and `_Iter_diff_t` resolve to `iter_reference_t`, `iter_value_t`, and `iter_difference_t` (respectively) in `__cpp_lib_concepts` (soon to be C++20) mode. This change necessitates some fixes to `unique_copy` and `_Fill_memset_is_safe` which both assume that `_Iter_value_t<T>` is well-formed for any iterator `T`. (`iter_value_t<T>` does not have that property: it is only well-formed when `readable<T>`.)
I notably haven't unified `default_sentinel_t` with `_Default_sentinel` out of an abundance of paranoia. Our `move_iterator` is comparable with `_Default_sentinel`, which is not the case for `std::default_sentinel`.
Drive-by:
* This change `if constexpr`-izes `unique_copy`.
This feature-test macro is being extensively queried, so we're updating it with high priority ahead of the other feature-test macro changes in this paper.
* Use unqualified function calls for valarray
The transcend functions require that the function is applied unqualified to each element
* Add comments to unqualified calls.
Fixes#285.
* Update `.clang-format` defaults.
* Enable `AlignConsecutiveMacros`, newly supported by clang-format 9.
We often followed this style before using clang-format, and I believe
that it produces generally positive changes.
* Apply clang-format changes.
* Replace `_FITS` and `_NEXT_ALIGN` macros. clang-format didn't damage
them, it just brought them to my attention. These macros weren't
improving clarity, and the code is more systematic without them.
(For the time being, I have refrained from further overhauling the
metaprogramming here.)
Fixes#187.
Add TRANSITION comments for #248 and #249, blocked by compiler bugs.
Add `_Enabled` names. When we don't have `enable_if_t`, this makes the
template parameter's purpose clearer. When we do have `enable_if_t`
but without `= 0`, this makes it somewhat clearer that we haven't
forgotten the default argument (it's simply elsewhere).
Resolves#55.
* Deprecate experimental::erase
* Implement P1209R0
* Update yvals_core.h
* Update deprecations and remove <experimental/xutility>
* move and reorder erase/erase_if
* moved _Erase and remove and friends to <xmemory>
* Consistently place erase_if() definitions.
WG21-P1614 "The Mothership has Landed" added `==` operators to the comparison category types (`weak_equality`, `strong_equality`, `partial_ordering`, `weak_ordering`, and `strong_ordering`) defined in `<compare>`. This PR implements those operators to bring the comparison category types up to spec once again. It also implements P1614R2's removal of operators that rewrite into calls to `operator==(X, nullptr_t)` for each comparison category type `X`.
Drive-by changes:
* Move the TODO list of tasks for WG21-P0768 "Library Support for the Spaceship (Comparison) Operator" completion out of `<compare>` and into microsoft/STL#64
* Remove the `#if 0 // Not yet implemented` block from `<compare>`
* Update required compiler versions
Update required version of MSVC to VS 2019 16.4p2, and Clang/LLVM to 9.0.0.
* Tell `<yvals_core.h>` that Clang 9 implements `consteval` (WG21 hasn't yet defined a feature-test macro for `consteval`)
* Tell `<atomic>` that Clang 9 implements the `__iso_volatile_load64` intrinsic on x86
* Update mentions of VS version in `README.md`
Resolves#85 / DevCom-706195
Casey applying the new atomic implementation fixed us breaking the
strict aliasing rules, but the memcpy is causing a code size regression
for non-`/Oi` customers. This change should restore code size for the
most common uses of atomic, which are `atomic<integral>` and
`atomic<pointer>`.
* Properly comment "Tukey's ninther".
* Remove workarounds for VSO-946746.
VSO-946746 "conditional explicit(bool) doesn't work with /clr:pure"
was fixed on 2019-07-23, and should be available in
VS 2019 16.4 Preview 1.
* Remove workarounds for VSO-433486.
VSO-433486 "_Count / 2 inside while (0 < _Count) loop is not
transformed into a simple shift" was fixed on 2019-08-27
and should be available in VS 2019 16.4 Preview 2.
Some shifts are still necessary, and are now commented.
* This mirrors a Microsoft-internal PR:
https://devdiv.visualstudio.com/DevDiv/_git/msvc/pullrequest/207988
`<any>` cleanup:
* Prefer variable templates to class templates
* Prefer `if constexpr` to tag dispatch
* Function pointers may be `noexcept` in C++17
* Remove the layer of "symbolic member name" functions to improve debug codegen
* Conventionally use `enable_if_t<conjunction_v<meow, woof>` instead of `enable_if_t<meow::value && woof::value>`
* Apply `_NODISCARD` and `noexcept` to internal functions as appropriate
* Allow overaligned types, which are properly handled by the `_Big` representation
Resolves [DevCom-724444](https://developercommunity.visualstudio.com/content/problem/724444/meow.html).
Clang's `__is_base_of` intrinsic incorrectly handles some corner cases involving incomplete union types before LLVM 9. Workaround by guarding with `__is_class`.
This is a back-compat fix for users who were saying things like
`std::memory_order::memory_order_relaxed`. As there is nothing
especially problematic about such usage, and LWG's ultimate resolution
is unknown, I'm not deprecating these enumerators at this time. If and
when this is voted into the WP in the deprecated clause, then we can
add deprecated attributes.
This mirrors a Microsoft-internal PR:
https://devdiv.visualstudio.com/DevDiv/_git/msvc/pullrequest/205250
* `array`, `basic_string`, `basic_string_view`, `valarray`, and `vector` (`span` is not yet implemented) model `contiguous_range` by defining the nested type `iterator_concept` to `contiguous_iterator_tag` in `iterator` and `const_iterator`, and specializing `pointer_traits` for those types (to fulfill `contiguous_iterator`'s `std::to_address` requirement)
* `basic_string_view` (Ditto, no `span` yet) models the exposition-only *`forwarding-range`* concept (which indicates that the validity of iterators is not bound to the lifetime of the range) by defining hidden-friend overloads of `begin` and `end` that accept rvalues
* Drive-by:
* mark the `_Unfancy` internal helper function `[[nodiscard]]`
* Remove redundant `_Can_begin` requirement from `std::ranges::_Begin::_Cpo::_Choose`
* Add test coverage to `devcrt/P0896R4_ranges_range_machinery`:
* tighten up `test_std_container`:
* `data` and `cdata` reject rvalue arguments since the returned pointer could potentially dangle (`contiguous_range` codepaths were lacking coverage)
* the `size_type` of a standard container can be other than `std::size_t` when using fancy pointers
* we should enforce that each container's iterator type models the expected concept
* Add test coverage to ensure that contiguous standard library containers model `contiguous_range` even when using an "old" fancy pointer type that does not model `contiguous_iterator`
Unions have "class type", despite that `is_class_v` is false for unions. Fixes a bug in which the behavior of `std::ranges::swap` cannot be customized for union types.
C4180 "qualifier applied to function type has no meaning; ignored" is emitted from `std::remove_reference<T>` when `T` is a function type or reference to such after applying the changes in #82. We could suppress it locally, but the warning is extremely low-value for the STL in general so let's simply suppress it globally.
This depends on compiler support that will first ship in Visual Studio 2019 16.4, so it's guarded to allow the build to work with current preview releases.
Resolves https://developercommunity.visualstudio.com/content/problem/274938/index.html
Replays VSO PR 199513, this is the last substantial change I hope to do before we can work wholly in GitHub.
* Implements a selection of support machinery in `std::ranges` and adds the `<ranges>` header. Primarily consists of the range access customization point objects:
* `ranges::begin`
* `ranges::end`
* `ranges::cbegin`
* `ranges::cend`
* `ranges::rbegin`
* `ranges::rend`
* `ranges::crbegin`
* `ranges::crend`
* `ranges::size`
* `ranges::empty`
* `ranges::data`
* `ranges::cdata`
and range concepts:
* `ranges::range`
* `ranges::output_range`
* `ranges::input_range`
* `ranges::forward_range`
* `ranges::bidirectional_range`
* `ranges::random_access_range`
* `ranges::contiguous_range`
* `ranges::sized_range`
* `ranges::view`
* `ranges::common_range`
and the associated type aliases:
* `ranges::iterator_t`
* `ranges::sentinel_t`
* `ranges::range_value_t`
* `ranges::range_reference_t`
* `ranges::range_difference_t`
* `ranges::range_rvalue_reference_t`
* Adds `<ranges>` - which is mostly empty since the support machinery is defined in `<xutility>` so as to be visible to `<algorithm>`
* Annotates [P0896R4](https://wg21.link/p0896r4) as partially implemented in the "`_HAS_CXX20` directly controls" section of `<yvals_core.h>`.
* Touches `<regex>`, `<set>`, and `<unordered_set>` to add partial specializations of `ranges::enable_view` for `match_results` and `(unordered_)?multi?set` as mandated by the WD to override the heuristic.
* Partially implements [P1474R1 "Helpful pointers for `ContiguousIterator`"](https://wg21.link/p1474r1):
* Push `pointer_traits` from `<xmemory>` and `to_address` from `<memory>` up into `<xutility>`
* Add `to_address` expression requirement to `contiguous_iterator` concept, and update `P0896R4_ranges_iterator_machinery` appropriately
* Implement the changes to `ranges::data` (but not `view_interface` since it isn't yet implemented)
* Drive-by:
* Simplify the definition of `pointer_traits::_Reftype` by eschewing `add_lvalue_reference_t`.
* Strengthen `reverse_iterator`'s constructors and `make_reverse_iterator` so `ranges::rbegin` and `ranges::rend` can be `noexcept` in more cases
* Since we're using `_Rng` as the template parameter name for models of `std::ranges::range`, rename a local variable `_Rng` to `_Generator` in `<random>`
Stephan T. Lavavej
Billy O'Neal
Pavol Misik
Michael Schellenberger Costa
Daniil Goncharov
Adam Bucior
Casey Carter
Daniel Marshall
Casey Carter
Michael Schellenberger Costa
Nikita Kniazev
Charlie Barto
Julie Philip James
SasLuca
Krystyna Lopez
S. B. Tam
SumanjaliDamarla
Nathan Ward
Stanislav Ershov
Andrew Fogarty
practicalswift