Distinguish between not present and not defined Args

[SuperFluffy]

Right now ArgMatches::is_present(s) checks whether the option with name s is present in the list of arguments or not. What about Args that have not been defined, and which I erroneously check for? Maybe is_present() could return an Option<bool> instead, with Some(bool) in cases where a defined Arg was set/not set, and None in cases where the option does not appear in the list of defined Args.

Assume the following example:

let m = App::new("myprog")
    .arg(Arg::with_name("debug")
        .long("debug")
        .short("d"))
    .get_matches_from(vec![
        "myprog", "-d"
    ]);

// Check with typo returns false
let is_present = m.is_present("dbeug");

This function will of course always return false. However, dbeug was never actually defined in the first place, so it would be great if it complained about that.

[kbknapp]

I agree this is an issue, and something I'm hoping to solve by proxy with the ability to use enums instead of strings (see #510). But this is all a breaking change and will be made on the 3.x branch which I'm hoping to get some time to work on in the next few weeks and actually be able to put out soon.

Having is_present return an Option<bool> could also be one of the breaking 3.x changes. I'm not opposed to it.

[kbknapp]

I think I'd prefer to panic! on an undefined arg. This will mean keeping a list of all defined args in the matches, which increases the memory usage quite a bit but perhaps only doing this in debug mode or behind a feature flag would be a good way to go about this.

[spwitt]

@kbknapp I've started working on this. I should have a pull request tomorrow after I update according to contribution guide

[vijfhoek]

For the record, I agree with using panic! for this. I think it is a really fair assumption that calling this on an undefined argument is a programming error, and not just a runtime error.

[CreepySkeleton]

This will mean keeping a list of all defined args in the matches, which increases the memory usage quite a bit but perhaps only doing this in debug mode or behind a feature flag would be a good way to go about this.

Emphasis on:

... only doing this in debug mode ...

This is pretty much the same as what we do for Id. Piece o'cake, I'll take it.