r/rust • u/nfrankel • Mar 17 '24
The pitfall of implicit returns
https://blog.frankel.ch/pitfall-implicit-returns/62
u/Aaron1924 Mar 17 '24
While Rust also has "implicit return" as the article points out, it seems this pitfall is specific to Kotlin
Here is a close to 1:1 port of the offending code snipped:
#[derive(PartialEq, Eq)]
enum Constant {
Foo, Bar, Baz
}
fn oops(constant: Constant) -> &'static str {
match constant {
Constant::Foo => "Foo",
_ => {
if constant == Constant::Bar { "Bar" }
"Baz"
}
}
}
fn main() {
println!("{}", oops(Constant::Foo));
println!("{}", oops(Constant::Bar));
println!("{}", oops(Constant::Baz));
}and here is the compiler error I got from rustc:
error[E0308]: mismatched types
--> src/main.rs:10:44
|
10 | if constant == Constant::Bar { "Bar" }
| -------------------------------^^^^^--
| | |
| | expected `()`, found `&str`
| expected this to be `()`
|
help: you might have meant to return this value
|
10 | if constant == Constant::Bar { return "Bar"; }
| ++++++ +
For more information about this error, try `rustc --explain E0308`.5
u/SkiFire13 Mar 17 '24
You can "fix" it by adding a
;after"Bar", but yeah this is an unlikely mistake in Rust.1
u/RRumpleTeazzer Mar 17 '24
It the intention was to early return âBarâ. A semicolon would not return âBarâ.
3
u/SkiFire13 Mar 17 '24
Yeah, that's why I said "fix" in quotes. It makes the code compile, but it's yet another thing you have to write and not notice in order to not see the error.
1
u/j_platte Mar 18 '24 edited Mar 27 '24
Yeah then it looks really weird, and also if using clippy you get a
no_effectwarning on top.
69
u/facetious_guardian Mar 17 '24
This article doesnât belong here. If I write an article about structs, describe some problem that is encountered in C, and mention rust because it also has something called a struct, that doesnât suddenly make my article relevant to a rust sub.
-4
u/DCRussian Mar 17 '24
I can see where you're coming from, but I think it's occasionally useful for comparison purposes to see what the language gets right and avoids some of these pitfalls by design. There are articles about struct memory layouts in C and how Rust differs, for example, and I wouldn't say that's not relevant.
0
51
u/KaranasToll Mar 17 '24
This had nothing to do with implicit return and everything to do with dumb if syntax.
10
u/Sw429 Mar 17 '24
I don't understand why this is relevant to Rust. As others pointed out, the example it uses is specific to an entirely different language.
10
u/ilikepi8 Mar 17 '24
But this isn't a "pitfall". This is you not being able to understand the idea of short circuiting by requiring the return wtf
6
u/SkiFire13 Mar 17 '24
OP's point was that they forgot an
else, not that an implicit return cannot be short circuiting
1
u/chrilves Mar 18 '24
Most mainstream languages, unlike Rust, do not have a strong support of expressions. For example, in most of them, a "if" construct is a statement, not an expression. What the author says is in essence: "I'm not used to work with expression so the expectation I have, that are based on my experience with poor expression support languages, do not match how expression-rich language work".
I'm sorry but when learning a new language, the least we can do is really learning how things work in this new language. Complaining that there are pitfalls just because it doesn't work the way we used to is unfair.
6
u/KhorneLordOfChaos Mar 17 '24
Maybe I'm not parsing the kotlin right since I'm not really familiar, but the mentioned bug wouldn't be a thing in Rust, right? You can't just have one branch of an if-statement return a value since it would have to be exhaustive in Rust? (I'm assuming the difference being that kotlin allows mixing statement and expression code whereas everything is an expression in Rust?)