If it's not the norm, I'd rather have an explicit "nil" or something at the end.
Also, because function signatures are never infered in Rust, mistakenly adding or forgetting the last semicolon will always result in a type error.
The most common pattern in my Rust code is:
`statement; statement; expression` where the expression is what I actually want to return from this function
it seems more noisy to say `statement; statement; return expression;`
Maybe I'll add a 'noreturn' keyword; single expresions are automatically returned, and you can use a 'noreturn' statement to explicitly return void despite running a non-void expression.
Something I've played with in languages I've worked on is named returns [1], which I like for that case.
[1] https://github.com/stormbrew/channel9/blob/master/sample/c9s... -- see the get function definition, '-> return' names the return 'channel' and 'return <- val' calls it (which returns). Now I might consider having an implicit '<- val' with no lhs that calls the current function's return, I think.
I do think a special case for single statements makes sense, though.
fn foo(x: bool) -> i32 {
if x {
1 // no semicolon on the 1
}
let a = 2 + 3;
return a * 4;
}
This rule means the scanning required is just looking at the end of the function.
In any case, having a static type system means I have never personally encountered a bug caused by this sort of implicit return in Rust.
Why aren't declaration statements in Rust just expressions that evaluate to the value being bound to the name being declared?
Would this mess up Rust's type checker somehow?