Yeah, these become a lot less relevant with routine.
Avoiding the main-thread panicking is mostly just a matter of not using .unwrap() and .expect().
String vs. &str can mostly be solved by generally using owned datatypes (String) for storing in structs and using references (&str) for passing into function parameters. It does still happen that you forget the & at times, but that’s then trivial to solve (by just adding the &).
“temporary value dropped while borrowed” can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.
“missing lifetime specifier” is also largely solved by not storing references in structs.
The last two points are the kind of design advice I need to see. I’m probably so used to the C/C++ concept of passing by reference to prevent copies of complex data being generated that I forget how Rust’s definition of a reference is different.
Yeah, these become a lot less relevant with routine.
Avoiding the main-thread panicking is mostly just a matter of not using
.unwrap()and.expect().Stringvs.&strcan mostly be solved by generally using owned datatypes (String) for storing in structs and using references (&str) for passing into function parameters. It does still happen that you forget the&at times, but that’s then trivial to solve (by just adding the&).“temporary value dropped while borrowed” can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.
“missing lifetime specifier” is also largely solved by not storing references in structs.
The last two points are the kind of design advice I need to see. I’m probably so used to the C/C++ concept of passing by reference to prevent copies of complex data being generated that I forget how Rust’s definition of a reference is different.