Includes:
* concepts `three_way_comparable` and `three_way_comparable_with`,
* type trait `std::compare_three_way_result` (with `_t` alias), and
* function object `compare_three_way`.
in `<compare>`, and:
* function objects `ranges::equal_to` and `ranges::less` (in `<xutility>` for
easy algorithm access), `ranges::not_equal_to`, `ranges::less_equal`,
`ranges::greater`, and `ranges::greater_equal` (in `<functional>`),
* slight refactoring of concept definitions in `<concepts>` to avoid redundant
requirements for the single-type comparison concepts `equality_comparable`,
`totally_ordered`, and `three_way_comparable`,
* heavy refactoring of the trait `common_comparison_category` (and `_t` alias)
in `<compare>` to requires only `n + c` template instantiations instead of `cn`
template instantiations,
* ======== ABI BREAK =========== remove the `_Is_unordered` member from
`std::partial_ordering` in `<compare>` since (a) it's true if and only if the
stored value has a particular value, and (b) Clang expects all of the
comparison category types to have size 1,
* reorder all `is_transparent` alias declarations in the STL to be after the
corresponding `operator()` to agree with synopsis order.
Also adds a new test `P0896R4_P1614R2_comparisons` that exercises the above.
The ABI BREAK sounds scary - as it should - but note that:
* this is a `/std:c++latest` feature, which is subject to change,
* objects of comparison category type aren't typically stored,
* only MSVC has released `<compare>` so far, so it's not widely used.
Altogether, it's extremely unlikely that anyone has encoded this in ABI.
* 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.)
* `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`
Adam Bucior
Michael Schellenberger Costa
Stephan T. Lavavej
Casey Carter