Describe the bug
C++20 now has indirectly_readable and indirectly_writable, instead of readable and writable. readable_traits has also become indirectly_readable_traits.

Expected behavior
Rename these entities!

Is your feature request related to a problem? Please describe.
The current mechanism for checking C2 subsumes C1 is completely ad-hoc. It'd be great for there to be a more formal way of checking this.

Describe the solution you'd like
Cleanly checking for subsumption may never be possible at a language level, but we might be able to force variable templates to do the check with well-documented values.

// Example 1
enum class subsumes {
   nothing,
   // public concept names here
};

template<typename...>
inline constexpr auto regular_hierarchy = subsumes::nothing;

template<destructible T>
inline constexpr auto regular_hierarchy<T> = subsumes::destructible;

template<default_initializable T>
inline constexpr auto regular_hierarchy<T> = subsumes::default_initializable;

template<move_constructible T>
inline constexpr auto regular_hierarchy<T> = subsumes::move_constructible;

template<copy_constructible T>
inline constexpr auto regular_hierarchy<T> = subsumes::copy_constructible;

template<swappable T>
inline constexpr auto regular_hierarchy<T> = subsumes::swappable;

template<movable T>
inline constexpr auto regular_hierarchy<T> = subsumes::movable;

template<copyable T>
inline constexpr auto regular_hierarchy<T> = subsumes::copyable;

template<semiregular T>
inline constexpr auto regular_hierarchy<T> = subsumes::semiregular;

template<equality_comparable T>
inline constexpr auto regular_hierarchy<T> = subsumes::equality_comparable;

template<regular T>
inline constexpr auto regular_hierarchy<T> = subsumes::regular;

static_assert(regular_hierarchy<std::mutex> == subsumes::default_initializable);
static_assert(regular_hierarchy<std::span<int>> == subsumes::semiregular);
static_assert(regular_hierarchy<int> == subsumes::regular);

Describe alternatives you've considered
No alternatives at present.

Additional context
The solution needs to be carefully curated, because we'll run into ambiguity problems otherwise.

// Example 2
template<typename...>
inline constexpr auto check_subsumption = subsumes::nothing;

template<semiregular T>
inline constexpr auto check_subsumption<T> = subsumes::semiregular;

template<equality_comparable T>
inline constexpr auto check_subsumption<T> = subsumes::equality_comparable;

template<regular T>
inline constexpr auto check_subsumption = subsumes::regular;

template<totally_ordered T>
inline constexpr auto check_subsumption = subsumes::totally_ordered;

static_assert(check_subsumption<int> == subsumes::regular); // error

In Example 2, we hit the problem that regular<int> and totally_ordered<int> are both satisfied, and thus specialisation becomes ambiguous. While it might be a valid compiler test to add a more specialised check_subsumption that requires both concepts, it doesn't benefit this test suite, which wants to check that regular subsumes semiregular and equality_comparable.

Is your feature request related to a problem? Please describe.
It would be nice for users to be able to explicitly specify the types that they use. For example:

#include "cjdb/iterator/reverse_iterator.hpp"

As opposed to

#include "cjdb/iterator.hpp" // reverse_iterator

Describe the solution you'd like
Move all non-detail headers out of the detail directory.

Describe the bug
Per the adoption of [P1870], ranges::begin and ranges::end depend on enable_safe_range, but this library doesn't have enable_safe_range.

Acceptance criteria
ranges::begin and ranges::end should both depend on enable_safe_range, and there should be an added test-case.

Is your feature request related to a problem? Please describe.
C++20 adds constrained comparison objects. Part of having a conforming implementation of Standard ranges is to support range.cmp.

This will add:

• cjdb::ranges::equal_to
• cjdb::ranges::not_equal_to
• cjdb::ranges::less
• cjdb::ranges::less_equal
• cjdb::ranges::greater
• cjdb::ranges::greater_equal

Is your feature request related to a problem? Please describe.
Manually trying get GCC to compile with concept bool is tedious and error prone, and should be automated.

Describe the solution you'd like
It would be nice if this project had a CMake script that could auto detect if a compiler requires concept or concept bool when supporting concepts.

Additional context
See cmake/FindSanitizer.cmake for an example of how this might be set up.

template<typename T>
constexpr auto operator()(T&& t) const
CJDB_DEDUCE_NOEXCEPT({
   return process(t);
})

is much easier to grok and makes the function feel more natural than what is currently in place.

Proposed resolution

1. Replace definition of CJDB_NOEXCEPT_RETURN with

#define CJDB_INJECT_LAMBDA(...) [&] __VA_ARGS__ ()

#define CJDB_DEDUCE_NOEXCEPT(...)                   \
noexcept(noexcept(CJDB_INJECT_LAMBDA(__VA_ARGS__))) \
{ return CJDB_INJECT_LAMBDA(__VA_ARGS__); }

2. Replace all occurrences of CJDB_NOEXCEPT_RETURN with CJDB_DEDUCE_NOEXCEPT.

Is your feature request related to a problem? Please describe.
Not everyone uses Conan. It'd be nice if there was an alternative package manager that's more lightweight, and this will also remove the dependency on Python that increases the size of Docker images.

Describe the solution you'd like
Add support for vcpkg, whilst keeping support for Conan.

Describe alternatives you've considered
No alternatives considered: other package managers should be requested per alternative feature requests.

When they become available.