[burntsushi]

Explicit returns are not frowned upon. I don't know where you got that idea. The only thing I can think is that this:

    fn foo() -> bool {
        true
    }

is preferred over

    fn foo() -> bool {
        return true
    }

But that's more of a style issue.

As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.

[falcolas]

> Explicit returns are not frowned upon. I don't know where you got that idea

From the docs:

http://doc.rust-lang.org/book/functions.html

> Using a `return` as the last line of a function works, but is considered poor style

[theseoafs]

Right -- explicit returns are frowned upon in the last line of a function, because they're absolutely not necessary, but everywhere else they're kosher.

[burntsushi]

Yes. Which is what I said. "Using a `return` as the last line of a function works" is not the same as "don't use explicit returns."

[falcolas]

So I should use `return` except when I shouldn't? This is the cognitive overhead problem I'm talking about.

The original context of my concern is the instance where the match statement makes up the last statement in the function (frequently the only statement in the function's immediate scope). Since the individual cases are not terminating the function early, to get a value out of a match statement you simply leave the last expression bare.

i.e.

    fn something... {
      match input {
      Ok(input_val) => {/* several lines of semicolon terminated code*/
                        output}
      Err(errval) => {/* several more lines of semicolon terminated code */
              output}
    } 

is correct, but

    fn something... {
      match input {
      Ok(input_val) => {/* several lines of semicolon terminated code*/
                        return output;}
      Err(errval) => {/* several more lines of semicolon terminated code */
              return output;}
    } 

is poor style, and

    fn something... {
      match input {
      Ok(input_val) => {/* several lines of semicolon terminated code*/
                        output;}
      Err(errval => {/* several more lines of semicolon terminated code */
              output;}
    } 

is an error.

[burntsushi]

> So I should use `return` except when I shouldn't? This is the cognitive overhead problem I'm talking about.

No. Use `return` only when you must. If you want an early return in a function, then you need to use `return`. If you don't need an early return, then don't use `return` at all.

I can't remember if this was ever a cognitive load for me personally. I don't think it was.

[falcolas]

> I can't remember if this was ever a cognitive load for me personally. I don't think it was.

Well, to be fair, it sounds like you're used to semicolons having special meaning (aside from separating expressions) from a previous language.

> As for `;`, it's just like Standard ML. `;` is for sequencing expressions. I love it.

It's worth remembering that most users of C, C++, Ruby, Java, Python, or whathaveyou are not used to the semicolon having special meaning. Since Rust appears to be primarily aimed at replacing C++, this is going to be a significant change which will likely trip people up for awhile.

[agrover]

I'm a C/Python person, and it did take a question on irc for me to get my head around how Rust does it, but now it seems so natural that it's a little irksome to look at some of my Python code :)

[pcwalton]

> This is the cognitive overhead problem I'm talking about.

The cognitive overhead of having the value of a function be the last expression in it is incredibly minor; lots of languages have this feature. Even JavaScript and C# have this with their arrow functions.

> …is an error.

The only time you get an error is if you tried to do something that you couldn't do in C++ at all (returning a value without typing return). I don't see how that would confuse C++ programmers. C++ programmers who write Rust using explicit returns everywhere will have their programs work exactly as they expect.

[Gurkenmaster]

>The cognitive overhead of having the value of a function be the last expression in it is incredibly minor; lots of languages have this feature.

This can cause performance problems in Coffescript because for loops are also expressions.