> ...people who get used to "everything is an expression" languages tend to prefer it, I've found.
This feels awkward as my mental model is that in "everything is an expression" languages you simply DO NOT offer "return" (and, if you do, it must be mapped to bottom and do something insane like throw an exception... but, like, if you are really used to using such a language, you'd never let yourself type a "return", as the entire concept feels icky and wrong in such a language).
Ruby is complex as it does the thing I said: 1) return is bottom, and so you can't have return "statement"--most people call it a statement even though it is a "void value expression"... but, like, once the type of an expression becomes sufficiently encoded in the syntax, how is it not a statement?--in a context where an expression would go; and 2) it isn't even the same thing as what Rust is doing, as it is a non-local construct that is effectively throwing an internal form of exception, allowing you to "return" from a function far up the call stack, and so it's rules are a bit more regular and useful: Ruby is coming at the notion of almost everything is an expression so as to allow expressions that look like statements, and that's a very different motivation than the syntax we are seeing here in Rust.
This feels awkward as my mental model is that in "everything is an expression" languages you simply DO NOT offer "return" (and, if you do, it must be mapped to bottom and do something insane like throw an exception... but, like, if you are really used to using such a language, you'd never let yourself type a "return", as the entire concept feels icky and wrong in such a language).