Die on missing uinput

[david-soto-m]

Hi, I saw your PR and saw that you requested some feedback on the Rust code. I must say that I am not really experienced, so take everything I say with a critical eye.

The return type

The main thing that I would change is the return Type. You use a boolean and then panic when it's false. I have used a Result type. The Result type has the benefit of forcing the user of your function to handle a possible error. Whether to panic or to try something else or set a default, the user is forced to do something with it. This is not the case with a bool type.

Another benefit of returning a Result is that every behaviour of your functionality is now inside your function, including information inside your panic messages.

fn panic_with_mess() -> Result<(), &'static str> {
    Err("here I am")
}

fn main() {
    panic_with_mess().unwrap();
}

returns a

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "here I am"', src/main.rs:6:23

See how the user of the function has had to call unwrap on the function result. If they didn't it wouldn't compile.

In the first commit I returned a standard result, but I later found out about the Kbct Error type and I have corrected that in the second commit.

() is the unit type in rust and the compiler knows how to optimize it and is frequently used in these cases. It's an empty tuple.

Aesthetics

The other changes I made are related to cargo-fmt and cargo-clippy- They are some really useful tools for Rust development.

fmt is a linter, that enforces style. It's used by running cargo fmt. This avoided long lines, mostly.

clippy is a tool that checks your code for common improvements and mistakes. It's used by running cargo clippy. This avoided an unneeded clone.

Currently, there is a lot that both those tools do, and I will make a PR with all the fixes they suggest to the main project, after they accept yours.

Else

If you are interested in learning Rust, I would recommend going through the rust book.

Sorry for my English

[david-soto-m]

So I added another commit in which I changed some .unwrap()s to ?. This has to do with the return type. Now that we have a result, the ? will pop up the error, rather than panic on the spot. I have, however, let one after the nth(2). This is due to that operation never panicking (I believe).

When there is a possible panic, you can avoid it occurring in the function by retuning an Err result with the error that has happened. Every time ? is used, you are doing a return Err(error that happened) in case there is an error and nothing when there isn't.