deny implicit returns

[imrn99]

Rust allows implicit return at the end of function:

fn implicit(x: u32, y: u32) -> u32 {
	x + y
}

fn explicit(x: u32, y: u32) -> u32 {
	return x + y;
}

While I think this is acceptable for small code bases, it creates inconsistencies and poor readability when complex control flow is involved. It is possible to deny this syntax using a clippy lint (clippy::implicit_return).

Should we enforce this rule? I personally prefer explicit returns, so I'm not sure if this is justified or if I am rationalizing too much.

[imrn99]

@cedricchevalier19 @franck-ledoux @dssgabriel opinions?

[dssgabriel]

Rust allows implicit return at the end of function

While implicit_return is the name of the clippy lint, Rust is more generally an expression-oriented language, i.e. the last expression of a block "implicitly returns". This shortens the syntax for, e.g., closures or ternary-like if statements:

it.map(|x| x * 2);

let foo = if bar > baz {
    7
} else {
    42
};

Explicit return statements are mandatory if, and only if the control flow of the function requires an early return.

From what I've read, Rust preferred code style is to use expressions instead of explicit return statements. There isn't any particular reasons for that, it seems to be inherited from the functional languages that inspired Rust (OCaml, Haskell, etc...) and is just considered more "rusty", see the description of the clippy::needless_return lint:

Why is this bad?

Removing the return and semicolon will make the code more rusty.

However, I agree that this may create inconsistencies in the code and affect readability. Some people also complain about rustfmt removing braces around expressions as implicit returns within closures:

fn find_foo(&self, bars: Vec<Foo>) -> Foo {
    bars.into_iter().find(|bar| {
        bar.baz == self.baz
    })
} 

gets formatted as:

fn find_foo(&self, bars: Vec<Foo>) -> Foo {
    bars.into_iter().find(|bar| bar.baz == self.baz)
} 

IMHO, at the end of the day this is just personal style and either one is fine. If you decide to go the "explicit return" route though, you may consider allowing needless_return as well.

Some discussions about the subject you may find worthwhile reading:

• https://www.reddit.com/r/rust/comments/2v82ag/why_isnt_the_syntax_of_return_statements_explicit/
• https://stackoverflow.com/questions/27961879/why-is-using-return-as-the-last-statement-in-a-function-considered-bad-style

[imrn99]

This shortens the syntax for, e.g., closures or ternary-like if statements:

I absolutely forgot these cases were technically returns, but from blocks.

IMHO, at the end of the day this is just personal style and either one is fine. If you decide to go the "explicit return" route though, you may consider allowing needless_return as well.

w.r.t. the above, a solution could be to allow needless_return & add them where they make sense.