Remove include <ranges>

[Bronek]

High Level Overview of Change

Remove dependency on <ranges> header, since it is not implemented by all compilers which we want to support. Resolves #4787

Context of Change

We only use ranges for std::ranges::begin and std::ranges::end, and for a matching concept. This can be trivially replaced with std::begin , std::end and an equivalent, trivial to write, concept.

The code change in question only affects unit tests.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (you added tests for code that already exists, or your new feature included in this PR)
• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)

[scottschurr]

Looks great. Works for me using Xcode 13.4.1.

[scottschurr]

Having slept on this, the current solution works for me. However, I'm having some pause about introducing a custom concept that is only used in one place. We could remove the concept and use a requires expression instead, like this:

template <typename Input>
auto
make_vector(Input const& input)
    requires requires(Input& v) {
                 std::begin(v);
                 std::end(v);
             }
{
    return std::vector(std::begin(input), std::end(input));
}

That would remove the need for a custom concept. Just a thought.

[Bronek]

Having slept on this, the current solution works for me. However, I'm having some pause about introducing a custom concept that is only used in one place. We could remove the concept and use a requires expression instead, like this:

template <typename Input>
auto
make_vector(Input const& input)
    requires requires(Input& v) {
                 std::begin(v);
                 std::end(v);
             }
{
    return std::vector(std::begin(input), std::end(input));
}

That would remove the need for a custom concept. Just a thought.

It's generic concept, and so is this function. I consider requires requires a little ugly - they are good to describe contract that a given function needs, but if something is generic enough I prefer to give it a name. Of course that raises a question of location of such a utility - the location is not generic at all here. But IMO it's better to have a named concept and plan moving it elsewhere in the future (how about XRPLF/toolset repo ?) rather than something that pretends to be very specific when actually it is not.

[seelabs]

I'm approving this, but in my opinion the concept doesn't add much. I probably prefer the code without the concept. The concept isn't used to help with an overload, and the expected interface of Input is trivially clear from code.

[Bronek]

I'm approving this, but in my opinion the concept doesn't add much. I probably prefer the code without the concept. The concept isn't used to help with an overload, and the expected interface of Input is trivially clear from code.

OK, I think appropriate compromise is to put a comment why this code is the way it is and why we need it temporarily i.e. because we do not yet have <ranges> on all supported compilers

[scottschurr]

👍

[Bronek]

@intelliot this is ready to merge