Remove magic arg type in Args
#197
Comments
Comment by epage Note to self: when implementing this, look into also implementing #2688 |
Comment by kbknapp The idea of using helper constructors |
Comment by pksunkara From the discussion,
|
Comment by epage Yeah, I got the idea from ripgrep which I copied until I switched to |
Comment by kbknapp @pksunkara I was thinking more about the long game of leave Just for backstory; I think the point I was trying to make in the thread between @epage and I was that currently since But this minor constructor problem is indicative of certain other similar cases in clap that can/do either cause confusion for the consumer, or ambiguities for clap parsing itself. Ambiguities aren't the worst thing, but they lead to implicit parsing rules, that if not specified somewhere can cause subtle breakage or cause unintended consequences as the API grows or evolves. clap's original design(tm) was deliberately different from something like Hopefully that makes sense, or at least captures some the "why" from the early days 😄 |
Comment by epage Thanks for the background! Unless someone has an alternative idea on how things might work, I don't think API optionsName-onlyfn positional(name: &str);
fn flag(name: &str);
fn option(name: &str);
Option-all-the-wayfn postional(name: &str);
fn flag(name: &str, long: Option<&str>, short: Option<char>);
fn option(name: &str: long: Option<&str>, short: Option<char>);
Helperfn new(name: &str);
fn postional(name: &str);
fn flag(name: &str, long: &str);
fn option(name: &str: long: &str);
|
Issue by epage
Friday Aug 13, 2021 at 19:27 GMT
Originally opened as clap-rs/clap#2687
Discussed in clap-rs/clap#2674
Originally posted by epage August 9, 2021
Arg::new()
creates a positional argument thattakes_value(true)
Args::new().long()
creates a named flag (takes_value(false)
)Args::new().long().takes_value(true)
is required to created a named arg / optionThis requires us to guess the users intent at various stages. kbknapp explained this when trying to explain existing challenges with
values
vsoccurrences
:I'm even running into a problem I'm debugging for #751 that I think comes from this.
Just a small tweak would make clap less brittle for change and I believe make the user experience better, if we switch to
Arg::new()
creates a positional argument thattakes_value(true)
Args::new().long()
creates a named arg / option (ietakes_value(true)
)Args::new().long().takes_value(false)
is required to created a flag@kbknapp was open to changing this, though with a different approach (this was before clarifying the approach above, see below for his thoughts on each approach)
We could fix the "always valid object" problem by instead making some helper constructors (
positional
,flag
, andoption
where the latter take long names since 99% of the time, they are used)Between flag-opt-in and construct invalid options (I didn't bring up the named constructors), kbknapp said
The text was updated successfully, but these errors were encountered: