Weird Expressions in Rust

This would be something the Boomer generation grew up with, and I think maybe the previous generation too. They're still around but they've certainly faded; they used to be Lego-level popular kids toys back then. They are named after President Lincoln, but only as a marketing tactic to use some of his reputation, there's no real connection.

I would imagine even some native English speakers are learning something with this post. I haven't seen them in a while.

There are very few statements: https://doc.rust-lang.org/stable/reference/statements.html

and a lot of expressions: https://doc.rust-lang.org/stable/reference/expressions.html

let y = match option { Some(x) => x, None => return Err("whoops!"), };

Without a type, the None branch loses the ability to unify with the Some branch. Now you could say that Rust should just only require branches’ types to unify when all of them have a type, but the ! never type accomplishes that goal just fine.

> don't even have a return keyword.

This is because they are not procedural languages, it has nothing to do with the type system.

> there is no upside that I can see to this decision in terms of language ergonomics.

There's tremendous upside! That's why lots of languages choose this. For example, there is no need for the ternary in Rust: if can just do that.

> What practical value is it to users to allow "return <expr>" to itself be an expression?

Code like this just works:

        let guess: u32 = match guess.trim().parse() {
            Ok(num) => num,
            Err(_) => return,
        };

    let day_number = match name {
        "Sunday" => 0,
        "Monday" => 1,
        "Tuesday" => 2,
        "Wednesday" => 3,
        "Thursday" => 4,
        "Friday" => 5,
        "Saturday" => 6,
        _ => return Err("invalid day")
    };

It makes generic code work without need to add exceptions for "syntactic elements". You can have methods like `map(callback)` that take a generic `fn() -> T` and pass through `T`. This can work uniformly for functions that do return values as well as for functions that just have `return;`. Having nothingness as a real type makes it just work using one set of rules for types, rather than having rules for real types plus exceptions for "syntactic elements".

  let name = match color_code {
    0 => "red",
    1 => "blue",
    2 => "green",
    _ => "unknown",
  };

> What practical value is it to users to allow "return <expr>" to itself be an expression?

Now, what if I need to return an error?

  let name = match color_code {
    0 => "red",
    1 => "blue",
    2 => "green",
    _ => return Err("unknown color"),
  };

There's more ways this "block statements are actually expressions" is useful. The need not be a ternary operator / keyword (like C, C++, Python, JS, etc.):

  let x = if cond { a } else { b };

  const x;  // but x's value will depend on a computation:
  // This is illegal.
  if(foo) {
    x = 3;
  } else {
    x = 4;
  }
  // It's doable, but ugly:
  const x = (function() { if(foo) { return 3; } else { return 4; }})();
  // (Yes, you can do this example with a ternary.
  // Imagine the if branches are a bit more complicated than a ternary,
  // e.g., like 2 statements.)
  

  let x = loop {
    // e.g., find a value in a datastructure. Compute something. Etc.
    if all_done {
      break result;
    }
  };

  let x = {
    // compute x; intermediate variables are properly scoped
    // & cleaned up at block close.
    //
    // There's also a slight visual benefit of "here we compute x" is
    // pretty clearly denoted.
  };

I think one can cook up weird code examples in any language.

I mean you don't see any of the nonsense in the blog post in any realistic PR (so they don't matter),

but you would run into subtle edge case issues if some expressions where more special then other expressions (so that does matter),

especially in context of macros/proc macros or partial "in-progress" code changes (which is also why `use` allows some "strange" {-brace usage or why a lot of things allow optional trailing `,` all of that makes auto code gen simpler).

Syntax alone can't stop sufficiently determined fools. Lisp has famously simple syntax, but can easily be written in an incomprehensible way. Assembly languages have very restrictive syntax, but that doesn't make them easy to comprehend.

Rust already has a pretty strong type system and tons of lints that stop more bad programs than many other languages.

Rust does not claim to be particularly security-focused, only memory safe.

Also, this means that you'd consider any expression-based language to be inherently a security problem.