nucleotide-count has no template

[BartMassey]

nucleotide/src/lib.rs should be

use std::collections::HashMap;

/// Count the number of occurrences of each of the four nucleotides
/// G, A, C, T.
pub fn nucleotide_counts(dna: &str) -> Result<HashMap<char, usize>, ()> {
    unimplemented!("Count the occurrences of G, A, C, T in {}.", dna);
}

/// Count the number of occurrences of a given nucleotide,
/// which must be either G, A, C or T.
pub fn count(nuc: char, dna: &str) -> Result<usize, ()> {
    unimplemented!("Count the occurrences of {} in {}.", nuc, dna);
}

Also, these should arguably return Option instead of Result, or just panic!() with a failed assert!() on bad input.

[petertseng]

As #444 indicates, using () for the error is not preferred, so let's find a better alternative. I'm down with Option, or having the err indicate an invalid character. Undefined exactly which invalid character out of multiple, but as long as we only have one unique invalid character in our inputs, we'll still be able to test for it.

That means I'd be down w/ Result<HashMap<char, usize>, char> and Result<usize, char> if desired.

[BartMassey]

If you're not down with having the functions be partial, I think Option is the best alternative. I don't think the Err return is going to be that useful in practice, as reflected by its lack of use in the tests.

[petertseng]

having the functions be partial

If you are willing to share your opinions, that would be a chance to influence policy. I imagine most of the exercises were made when https://doc.rust-lang.org/book/first-edition/error-handling.html was the only edition of the book. It barely mentioned panics. To be fair, it did mention in https://doc.rust-lang.org/book/first-edition/error-handling.html#a-brief-interlude-unwrapping-isnt-evil that panicking should indicate a bug in the program.

These days there's https://doc.rust-lang.org/book/second-edition/ch09-00-error-handling.html and various subsections

• https://doc.rust-lang.org/book/second-edition/ch09-01-unrecoverable-errors-with-panic.html
• https://doc.rust-lang.org/book/second-edition/ch09-03-to-panic-or-not-to-panic.html

For example, perhaps the sentence is relevant:

If someone calls your code and passes in values that don’t make sense, the best choice might be to panic! and alert the person using your library to the bug in their code

If this is to be the case, when would be a situation where the Rust track would want to use Result or Option in a non-contrived way, then?