My confusion stems from the following code, specifically line (marked by me):
fn first_word(s: &String) -> &str {
let bytes = s.as_bytes();
for (i, &item) in bytes.iter().enumerate() {
if item == b' ' {
return &s[0..i];//HERE <<< why do I have to use return not just &s[0..i]
}
}
&s[..]//HERE I actually don't use return and it compiles!!!
}
What's more, the code will simply not compile if I don't use return!!!
I always thought that in order to indicate return statement in rust one simply doesn't end line with semicolon. That's obviously wrong as the above example is showing.
Any ideas why and how to understand this behavior?
A function will return the last expression automatically. The last expression here &s[..].
If you want to return early, as in the loop, an explicit return is needed.
If you remove the return in the if, then you are trying to assign the value &s[0..i] to the if-expression, which fails as if expressions can only take a value if they have an else-block. The return statement explicitly returns from the function now, instead of just assigning the value to the surrounding block.
The ints are first assigned as the value to the if. Then, since the if is the last thing, the value of the if (which is one of the ints) becomes the value of the function.
Thanks for the answer.
To me this kind of behavior is simply confusing. Why can't we simply not put the return? I mean, it makes the whole returning in rust rather peculiar. There are places where one doesn't use return, there are other places where one must use return. Mess.
@s3bk
Sure but this is really, really confusing. By this I mean:
42;//returns () - kinda pointless, where function sig specifies that it doesn't return anything
42 //returns 42
return 42; //returns 42
It is confusing that you sometimes have to specifically write return and in some (most) cases you don't.
Tbh, I've learned few languages in my life and never had an issue with the way we return from functions.
It is clear but convoluted/surprising/confusing for newcomers. In rust in order to return from function sometimes you are forced to use return, sometimes you don't have to but you can. << This is confusing.
Maybe one part is that in Rust, there are often many ways of solving a particular problem. It is totally fine to ignore iterator adapters and start with for loops, use explicit return everywhere and always write the return signature.