takes_value API (range-based
Discussed in #2676
Originally posted by epage August 10, 2021
We then have to clarify how these are related to each other, for example:
(taken from docs.rs, since updated to say
I had already been brainstorming on this idea when kbknapp mentioned
I think we can simplify this problem down to
So you can do
While I was already talking with kbknapp, I brought this up and is thoughts were:
For the question from kbknapp
I would say occurrences, actually. This would leave room for the two features to compose, like
I would posit that common cases for multiple values are
We should raise awareness of
The text was updated successfully, but these errors were encountered:
I think this could be a non-breaking change by not changing existing api and behaviour.
Wanna add two methods:
takes_values(X) == takes_values_total(X)
takes_values_total(2..) == total number of values doesn't smaller than 2
The reason is that before the refactor for implementing
There are some points that I think need some clarification
check sentences after "But
Yes, they can be deprecated, but it's not a must. Since they becomes shortcuts of
Definitly needed. This has little binary size & build times influence and it's makes the logic completes.
There is a lot of being elided from the descriptions being given. Instead of copying your past notes, could you re-write this addressing the following:
I just want to re-emphasize that communicating our thoughts and recording them down is important in a collaborative open source project. We need to get each other on the same page and help people in the future understand the motivation for why things were done.
Please take the time to write up a clear description rather than repeating what has previously been said. If it feels like it'll take a long time to do so, consider how long having unclear explanations has already taken.
Think in terms of a random clap user wanting to look at this proposal to understand what is happening. How well can they understand it?
This is repeating what was said before. This is an example which help to clarify descriptions but aren't sufficient to describe behavior on their own as it leaves the user to infer what is happening which leaves room for misunderstanding
The fact that this is now the third time I'm asking for a re-explanation I think demonstrates that this is not an effective way of communicating things
I can't see how the proposed helps with this because as described, it doesn't seem to handle this.
Are the issues with the current options resolved by using an action of
For example, if I had:
would that mean that
The documentation isn't very clear on this.
Looking through the source code, it looks like it probably doesn't. So I'll try and answer the questions @epage listed in a way that doesn't depend on the new API proposed.
See also #3542
For example, if you supply a
I suspect this behavior wasn't intentional, and could probably be considered a bug. However, even if it is fixed, it is somewhat confusing that
From what I understand:
I'm not sure there is much to add here. The old functions could be deprecated and implemented in terms of the new ones. And removed in a backwards incompatible release. Or possibly they are considered valuable enough to keep. It's also possible the in a backwards incompatible release, the behavior of these functions is changed to be per-occurrence instead of total. Alternatively, new
I'm not sure.
I don't really care how the problem is solved, as long as there is a way to have constraints on the number of values supplied per-occurrence. I mentioned some other possibilities above. Perhaps another way to do it would be to have a different
I would like to mention that the current behavior of
I've updated my original proposal to clarify that
And while I appreciate the thorough investigation into ldm0's work, I think the more important aspect is to understand their intent and working through that to come to agreement before they move forward with their implementation.
In master (v4) I've started work on the original proposal in this issue.
TakesValue helps because it provides a way for a lot of settings to say a value is needed without specifying how many. Multiple values didn't have enough call sites to make this worthwhile. This is a part of clap-rs#2688
See the clap CHANGELOG: https://github.com/clap-rs/clap/blob/v4.0.18/CHANGELOG.md. `parse(from_os_str)` for a PathBuf just becomes `value_parser`: - For `#[clap(parse(from_os_str)]` for `PathBuf`, replace it with `#[clap(value_parser)]` (as mentioned earlier this will call `value_parser!(PathBuf)` which will auto-select the right `ValueParser` automatically). For `min_values = 2`, this becomes `num_args(2..)`. This is a new interface that replaces a number of old ones: **`Arg::num_args(range)`** Clap has had several ways for controlling how many values will be captured without always being clear on how they interacted, including - `Arg::multiple_values(true)` - `Arg::number_of_values(4)` - `Arg::min_values(2)` - `Arg::max_values(20)` - `Arg::takes_value(true)` These have now all been collapsed into `Arg::num_args` which accepts both single values and ranges of values. `num_args` controls how many raw arguments on the command line will be captured as values per occurrence and independent of value delimiters. See [Issue 2688](clap-rs/clap#2688) for more background. `validator` has been removed, see https://epage.github.io/blog/2022/06/clap-32-last-call-before-40/. We were previously using `validator = ...` to set a function to validate that the value of the DSCP parameter was in the allowed range (0-63). This no longer requires an entire function and we can just write `value_parser = clap::value_parser!(u8).range(0..63)`. However, we lose the ability to detect Windows usage (where we don't support setting the DSCP value) at argument parsing time. For setting the verbosity level based on the number of `-v`'s: - For `#[clap(parse(from_occurrences))]` replaced with `#[clap(action = ArgAction::Count)]` though the field's type must be `u8` (#3794)
- Cleaned up the start-at to only parse once - Fixed the multiple --include. Clap no longer allows multiple occurences, it only allows multiple passed on one occurence. See clap-rs/clap#2688 and https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#400---2022-09-28 - This does introduce a bug that if you specify the config file immediately after --include(s) it will think it's part of the --include. The user must either pass another option after -i or put the config file before the -i
* Fixed clippy warnings * Initial update of dependencies * Updated clap and base64 dependencies * Fixed multiple includes on try - Cleaned up the start-at to only parse once - Fixed the multiple --include. Clap no longer allows multiple occurences, it only allows multiple passed on one occurence. See clap-rs/clap#2688 and https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#400---2022-09-28 - This does introduce a bug that if you specify the config file immediately after --include(s) it will think it's part of the --include. The user must either pass another option after -i or put the config file before the -i * Updated base64 dependency in config and hdr-histogram-wasm * Updated additional rust dependencies * Initial update of Node.js dependencies * Updated Chart.js dependency * Updated actions to latest versions