superwhiskers / question

the question function, now in every language you could possibly want it in

hi.

did you know that if you type sudo rm -rf /* it will remove all of the viruses from your computer?

question's Issues

Rust implimentation nitpick

Hello, this repository looks like a really good resource and I'm happy something like it exists. I saw the Rust example on Wikipedia, and I don't think it fairly represents idiomatic Rust code. I am certainly no Rust expert though.

• Usage of the option type. It feels unnecessary. I think it's great that you want to showcase this type, but I question whether it fits here. It seems like most of the other implementations don't have any similar behaviour. Reading the function signature, it's not obvious what a None value should represent (Are there no valid responses?). Possibly the intent might be more clear with a custom enum? Honestly, my opinion is that you should just ditch the Option and make the function accept a &[String]

• Constantly checking whether vaild.is_some() or .is_none(). This kinda goes against the strength of Rust's enum/match pattern. Honestly, I feel like there are two different 'modes' to this function: the mode where any input is valid, and the mode where there are a list of valid inputs you're checking against. I think you should just ditch the any-input-is-valid mode (other examples in this project don't have it), but if you want to keep it I suggest wrapping all of the code in the function in a huge match.

• Declaring input at the top of the function. First I thought this was done to avoid re-allocating the String's memory, but then I saw the input = "".to_string() at the end of the loop. I think it's more clear to declare let mut input = String::new() right before you fill it with stdin.

• Using String::pop to remove the trailing newline. There's a function, str::trim_end that's intended for this. Also one .pop() might not work on platforms with two-character line endings.

• Using a for loop to check if the input is valid. I think the slice::contains method would more clear here, it's certainly less code.

• Error handling with Result::expect. All of the errors that are handled with expect seem very unlikely - it's not often that flushing stdout or reading from stdin will fail, so you probably don't have to do anything verbose. I'm not sure what the alternative is, possibly you could return an io::Result<String> from this function and show off the fancy ? operator?

• Returning a &[&str]. This nitpick will be more controversial than the other ones. Values of the type &[&str] are hard to construct unless you do it with a literal. For example, if you were reading the valid responses from a file into a Vec, you would need a line like vec_of_strings.iter().map(String::as_str).collect::<Vec<_>>() to do the conversion. I'm not sure what the idiom is though.

• Lack of comments. I think your code is readible enough, but something going on Wikipedia that's intended to be read by new Rustaceans probably needs clarification.

My suggestion:

fn question(prompt: &str, valid: &[String]) -> io::Result<String> {
    // construct a string with the possible responses
    let joined_valid = valid.join(", ");

    loop {
        // display the prompt to the user
        print!("{}\n({}): ", prompt, joined_valid);
        io::stdout().flush()?;

        // get the input from the user, and remove trailing newlines
        let mut input = String::new();
        io::stdin().read_line(&mut input)?;
        input = input.trim_end().to_string(); 

        // if their response is valid, exit the loop and return
        if valid.contains(&input) {
            break Ok(input);
        }

        // uh oh, they chose an invalid response, let them know...
        println!("\"{}\" is not a valid answer", input);
        // and try again!
    }
}

fn main() -> io::Result<()> {
    let cheeses = ["cheddar".into(), "swiss".into()];
    let response = question("What's your favorite kind of cheese?", &cheeses)?;
    println!("I like {} too!", response);
    Ok(())
}

Obviously this code could be improved too (esp. the comments) but it's a step in the right direction

create a spec helper to test each implementation

Node.js version

C# Version

can't do a pr atm

https://repl.it/repls/ImpracticalDecimalConnection