Improve the -u flag once clap is ready

[Byron]

I'd like to have -u <mode> <file> <mime>, and all we need is an improvement, as suggested in this issue.

[kbknapp]

Should be ready with 0.7.1 on crates.io ;)

[Byron]

You can watch the development stream in multiple sessions on youtube:

• updating the upload flag part 1
• updating the upload flag part 2

[kbknapp]

I'm really enjoying the videos as it's showing me from an outside perspective things I can improve!

I haven't watched part 2, as it's still processing - but I noticed in part 1 you mentioned possible values for each different value of -u, which currently isn't implemented, and I'm not sure it will be - at least not soon ;) . One method to work around this is what you ended up doing with an enum and using parse(), and just in case you hadn't seen it, there is a macro in clap that creates an enum and automatically implements std::str::FromStr, as well as another macro to retrieve the value. Check out the arg_enum! macro if you're interested (also some examples in examples/ dir, namely the TypedValues ones). The downside, is you don't get the valid possibilities printed in your help or usage strings on error, although this is something that can still be done manually as parse returns a Result. Also, it's case sensitive, so you either have to allow variants without camel case to suppress the warning, or just be aware of that.

The gist is something like:

arg_enum!{
    #[derive(Debug)]
    enum FirstValue {
        value1,
        value2,
        value3
    }
}

arg_enum!{
    enum SecondValue {
        value1,
        value2
    }
}
//...
for (i, val) in values_vec.iter().enumerate() {
    match i {
        0 => {
            // .unwrap() just for brevity
            let first_val = val.parse::<FirstValue>().unwrap();
            println!("First val: {:?}", first_val);
        },   
        1 => let second_val = val.parse::<SecondValue>().unwrap(),
        _ => ()
    }
}

[Byron]

@kbknapp Thanks a bunch for the hints ! It's quite cool to see you find the videos useful ! Actually I watched part of the sessions myself just to find (and fix) the mistakes I did. It also gave me a clearer view on the situation, which led to a proposition for improvement.
The arg_enum! macro I would love to use, as it would reduce code-bloat on my side, but I believe it doesn't support remapping yet ? This is as I'd like to have capitalized enum variants, but allow the matching strings to be lower-case, so that the following can work:

match "simple".parse() {
    Ok(Protocol::Simple) => <this branch should match>,
    Ok(Protocol::Resumable) => ...,
    Err(err) => ... ,
}

From the docs and the implementation, it didn't look like that would work, but I admittedly didn't try it either.
Edit: You mentioned the camel-casing issue as well :) ! So for now I will just go with the manually implemented version.

[kbknapp]

PR 105 adds ascii case insensitivity for enum variants. So you could have an enum

arg_enum! {
    enum SomeVal {
        ValOne,
        ValTwo
    }
}
// ...
match value_t_or_exit!(matches.value_of("my-enum"), SomeVal) {
    SomeVal::ValOne =>(),
    SomeVal::ValTwo =>(),
}
// "valone".parse::<SomeVal>() works too

If the user ran $ myprog valone or $myprog ValOne it would still match SomeVal::ValOne. The catch is it only supports ASCII characters (for case insensitive), and only simple enums are supported (i.e. not tuple structs, struct variants, etc.). Just FYI ;)

[Byron]

Thanks again ! Now it is exactly what I need, and I will use it as soon as the PR was merged.