-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support parsing values from options #7
Labels
Comments
platisd
added
enhancement
New feature or request
good first issue
Good for newcomers
labels
Dec 5, 2022
I don't think the "ideal" syntax is feasible, so let's go for something like this instead: using CommandParser::operator""_i; // Integer option
using CommandParser::operator""_b; // Boolean option
const auto get = UnparsedCommand::create("get", "Get configuration key", "[-xyz] <key> [default]")
.withOption("intOptionName"_i) // --intKeyOptionName <someFloat>
.withOption("boolOptionName"_b) // --boolOptionName <true|false>
.withOptions({ "x", "y", "z" }) // Should this still work? Open for discussion
.withArgs<std::string, std::optional<std::string>>(); And then: const auto intOption = parsedCommand.getOption("intOptionName"_i); // return is std::optional<int> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now options (i.e. command line arguments that start with
-
or--
) have an implicit boolean value,true
if they are present andfalse
otherwise.It would be cool if we could support the following syntax for all the types we already support:
Regarding
bool
options and implicit values (i.e. a user does not have to specifytrue
orfalse
after them, I am thinking that we probably need to specify in advance whether a value is expected or not, otherwise there will be confusion with the positional arguments that are the library's primary use case.Resolving this is not a priority, i.e. it's fine if they have to be explicitly set.
When it comes to fetching values, I think that everything should be an
std::optional
. If the option is not there, thenstd::nullopt
should be returned. In thebool
case maybe we can keep the current API withhasOption
. OK to remove.Anyway, to fetch the value of an option, one should ideally do, not sure if possible:
Otherwise:
The text was updated successfully, but these errors were encountered: