[simias]

It's actually super nifty and IMO a great feature. However I think one of the reasons it works so well is that Rust is statically and very strongly typed, in a more dynamic language it would be hard to keep track of what's going on.

An other reason it works is that almost everything is an expression in Rust, including things like `if` statements. So for instance you can write:

    let message =
        if auth_ok() {
            "success"
        } else if tries < 3 {
            "try again"
        } else {
            "failure"
        };

If you add semicolumns after the strings the `if` will always evaluate to nil here.

Note that this won't work if one branch returns string an and other returns an integer for instance since the type of "message" must be known at compile time.

It also works well for getter functions and lambdas, for instance:

    fn is_empty(&self) -> bool {
        self.len == 0
    }

or:

    list.sort_by(|a, b| a.key < b.key);

This way you focus on what's important.

I can see where you're coming from though, it's easy to dismiss this feature as a bad idea on paper, especially if you've been traumatized with Javascript's insane handling of semicolumns. In practice however it's a rather useful sugar and so far it's been harmless in my experience. It basically makes the language more lispy.

[tomp]

I read your comment more as an endorsement of implicit returns. Make no mistake, I love those. I've been using them most of my life, first in OCaml and then in Scala.

I just think that using the semicolon to make the function return unit instead is problematic. It would be better to have the type system guide that decision, like in Scala. It would be even better to have an explicit `ignore` function or something (like in OCaml) to signal to the compiler that you really want to ignore the value and you only care about uthe side effect. I mean, why would you ever write just e.g. `a < b;`?

[simon_o]

> I just think that using the semicolon to make the function return unit instead is problematic.

Agree. The idea to attach additional semantics to ; is completely nuts, especially as ; is mandatory in Rust (usually, there are odd corner cases where it is not allowed).

Just get rid of mandatory ; completely and let the type system handle the rest.

[simias]

; is used to separate statements, how do you propose to get rid of that?

I guess you could use significant newlines like python but I never really liked that. I think Rust's compromise is pretty decent.

In particular it's the first time I hear people complaining about it, so far most users (myself included) seem to be praising it. Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.

[simon_o]

It's 2017, I'm not placing ; by hand anymore.

We have computers they are perfectly able infer them for me.

> Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.

- JavaScript does insane things, as usual. This doesn't mean every implementation of semicolon inference has to be that bad and broken.

- Rust goes the other way by pretending it's still 1990.

There are plenty of languages out there that handle semicolon inference perfectly fine.

(Heck, I even let the IDE show me where the compiler has placed them.)