Closed andoalon closed 2 years ago
Sorry for the really late reply. All good ideas. I'm thinking about the best direction. And thanks for offering to help. But I'm going to go ahead and implemented something int he next few days to resolve it. Since it would be unfair of me to ask you to do the work after such a long time.
Nice! Let me know if I can help, I'm still 100% open for collaborating/discussing (I don't think it's unfair for you to ask for help), I was just unsure what the best direction was. Thank you for your work 😊
I realized that there is a corner case when parsing flag options: if the command-line contains a value for the flag, it will get ignored, which can be confusing:
The reason for that seems to be located in
opt::parse
:I initially tried to make flags optionally accept values, so that if no value is provided,
true
is used, and the value otherwise:--wait-for-input
-> true--wait-for-input=yes
-> true--wait-for-input=no
-> falseThe code looked something like this:
Unfortunately, this doesn't work in practice:
--wait-for-input=yes
or--wait-for-input no
) it works ✅--wait-for-input
), it seems to work...--wait-for-input --other-option=3
->Unable to convert '--other-option' to destination type
❌Therefore, my suggestion would be to not accept values for flag options at all, but make sure that no value is provided with a delimiter:
While we are at it, we might also add some extra validation that checks that no
value_choices
are provided for flags (choices don't make sense for them, as far as I know):Please let me know if I misunderstood something, and give me feedback if you like the idea so that I can create a pull request. Thank you for the awesome library!