Don't listen to these official Rust developers, the real reason is that they're secretly functional programmers who would rather corrupt you into using Rust's implicit return values rather than the holy return statement.

  fn heresy() -> &str { "I am the corruption lurking in your heart" }

And not a semicolon in sight. Disgusting.

For brevity, doesn't type inference work in this case? (I'm not up to speed on the language evolution).

fn heresy() -> { "I am the corruption lurking in your heart" }

Graydon (the Rust BDFL) has always been adamant about being explicit about types in function signatures, so no, you can't infer the return type there. I personally agree with this decision, since such an important part of using any API is knowing exactly what to put in and exactly what you're getting out.

However, closures are allowed to have all of their types inferred. This is because closures aren't allowed to exist at the top level of a file (in what's called "item position"), and so you don't really have to worry about them being used by others. The closure equivalent of the heresy example would be:

  // Note that the braces in this line are optional
  let heresy = || { "I am the corruption lurking in your heart" };
  // Though you're still allowed to be explicit, if you'd like
  let heresy = || -> &str { "I am the corruption lurking in your heart" };

We like brevity in our keywords, but we felt that "ret" was taking things a little too far. "return" met our 5-characters-max criteria, so we switched.

edit: Ho ho ho, I can't count. And we don't really have a 5-character-max criteria, but we do prefer shorter keywords.

> "return" met our 5-characters-max criteria

I'm curious as to how this conclusion was reached.

Well, the actual keyword is retum. It turns out that most humans can't tell the difference between an r and an n next to each other, or the letter m, so they just decided to go with the quicker to type 'm' instead or 'rn' You've just been reading it wrong.

:D Honestly, I think either ret or return is fine, but I'd match other keywords. So if you're using pub and priv instead of public and private, I'd use ret instead of return as well.

Oh boy I can't count. That criteria is a little tongue-in-cheek. Basically the core developers decided saving those extra three characters wasn't worth it. We implicitly return the last expression, so "return" is typically only used for an early exit. Therefore it's more approachable to new users, and pretty rare so it doesn't add much clutter.

The 'r' is the zeroth character of course.

I think you made the right decision about 'return'. btw, if you're also changing 'alt', why 'match' rather than something more familiar to C programmers like 'switch'?

Also, did you consider pythonic 'and' and 'or' keywords? Typing 'or' requires fewer keystrokes than || (and 'and' requires no more than &&). Plus, neither requires any shifting! I know Rust developers are lazy typists. ;)

Also, more readable. Personally, I think it's sad that Rust (along other systems-oriented languages like D and Go) haven't taken more of the syntax from Python, which I find to be superior to the world of curly braces.

Agreed. Especially since Rust uses a lot of different sigils already (@ , ~, &, ::, <>, || for closures...). Using and/or, hopefully along with significant whitespace would reduce the visual clutter.

Sometimes I'm a little sad about && and || as well (I'm a Python guy myself) but I get that Rust is trying to target C++ programmers first and foremost, and a little bit of familiarity goes a long way towards comforting newcomers. And judging by the number of self-proclaimed Python programmers lurking in in #rust (including at least one quite famous one), it hasn't been a complete turn-off.

Then again, the "C familiarity" rationale would seem to contradict the choice of `match` over `switch`, though I think pattern-matching is a sufficiently big deal to warrant a distinct keyword. It's an interesting comparison to Rust's old `tag` keyword, which was finally changed to `enum` because the easiest way to explain it was "look, they're basically C enums, but better". Personally I think the keyword should have remained `tag`, but you can't win 'em all. :)

It's named after the alternation style used, which is well established in other languages.

Just make sure things stays very consistent and readable, I think that's the most important.

I don't think ret vs return is big deal. Both are understandable and relatively short, or expected. On the contrary, odd unknown, new syntax may sometimes be.

Good job on the new release :)

IMO, return is pretty standard and most people are familiar with it or get it right the way. Ret requires extra mental parsing at first.

With editor's code completion, it's really no big deal with the extra 3 chars. Alt-/ does the magic in Emacs.

Also people who really don't like the typing can use the implicit return expression.