4 ms·
> The Rust version requires you to use your intuition to figure out that `unwrap()` will never panic here. You should not use `unwrap` in a production product.
by csomar 5y ago
> The Rust version requires you to use your intuition to figure out that `unwrap()` will never panic here.
You should not use `unwrap` in a production product. It's there for prototyping and I think it's a mistake they have it (though the language already requires a good upfront time investment as it is). Use `?` and have your error propagate accordingly to the top of the chain. Have your own error types and convert from other error types.
if !some_vec.empty() {
print!("{}", some_vec.first().unwrap());
// .. more code
}
I don't know why you would check the first element of a vector. Use Rust type system to your advantage, and don't "convert" PHP code into Rust. Re-design your program. Also you don't need to check that the Vector is empty if you are using "first". "first" returns an Option with None if your vector is empty. My guess is that you have yet to exhaust the idioms Rust offers and approaching it in a PHP-like manner.
> > At the cost of introducing a bug/technical debt.
> At the cost of shipping a product!
Okay!
- verdagon 5y agoWe tried this style in one of Google Earth's packages for a while (using an internal C++ class similar to Rust's Result). So many operations could theoretically fail (e.g. indexing out of bounds or an expected key not existing) that pretty much every single function in that package returned a Result. These "unexpected" errors would just fly up the stack, manually unwinding it, because nobody could really do anything with them. Once we had that, I really questioned some of our policies. I can imagine a language where panics don't crash the entire application, but instead blast away the surrounding "region" of memory, leaving the rest of the program intact and able to keep running. Similar to catch_unwind, but if the language is aware of region boundaries, and only allows certain methods of communication between them, it would leave the rest of the memory in much more predictable possible states. It may sound surprising, but it's actually possible with the right language constructs (Erlang folks know what I'm talking about!) and that way, we could once again have panics for unexpected errors, and Results for expected errors.
- Too 5y agoSounds like what you want is how exceptions behave in most languages? Including c++?
- muglug 5y ago> don't "convert" PHP code into Rust. Re-design your program. Trust me, I am! For example, I'm rewriting all the (very-efficient) PHP regex code to a much more convoluted version because Regex::new is so costly. Less sarcastically, I am embracing the Rust Way where necessary. My complaint is that the Rust Way sometimes forces me to depart from the idealised pseudocode version of a given algorithm much more drastically than PHP does.
- Gwypaas 5y agoAny reason why you can't put the Regex in a once_cell and then keep on applying it?
- mustache_kimono 5y agoWait... You're rewriting the PHP regex code instead of using the regex crate?! Just...wait...why? Are you using lazy_static? See: https://docs.rs/regex/latest/regex/#example-avoid-compiling-the-same-regex-in-a-loop https://docs.rs/regex/latest/regex/#example-avoid-compiling-...