Potential improvements to rfl::cli::read() API

[axel-dewalt]

First of all, thanks for such a useful addition to the library!

I have some questions and suggestions for further improvements to its API:

1. Could rfl::cli::read()'s argv param be const? Currently it's defined like:

rfl::Result<T> rfl::cli::read(int argc, char* argv[]);

Some programmers declare their argv as const, I understand this is legal. If the API was changed to this, then it would support parsing arguments regardless of whether they're declared const or not:

rfl::Result<T> rfl::cli::read(int argc, const char* argv[]);

Given that you don't appear to be writing to argv, I think this is quite possible and desirable.

2. Additional alternative API that allows the arguments to be passed as a range/sequence.

It is not always the case that arguments will be coming in straight from the C entry point, sometimes there is a framework or some other wrapper handling them. It would be convenient if reflect-cpp would support the ability to pass in say, a std::span, range or view over the argument strings (also dispensing with the separate count argument, count to be taken directly from the input sequence object):

rfl::Result<T> rfl::cli::read(std::span<const char*> args);

3. Don't ignore the first argument in the arguments array.

The use-case here is if it's not the full list of arguments from argv being passed into the function, but rather a subset of arguments (imagine a program that already handles the "front" arguments itself, and is using reflect-cpp to parse the remaining arguments).

I'd love to know what you think. I can probably find some time to contribute these changes myself if you like the proposals.

[liuzicheng1987]

Hi @axel-dewalt , I think all three changes sound great!

[axel-dewalt]

Hi @axel-dewalt , I think all three changes sound great!

Great! I will aim to find some time this week to make them and will send you a pull request when ready for review.