Hacker News new | ask | show | jobs
by steveklabnik 360 days ago
> Return is a statement in the minds of most programmers

I would take issue with this, sure, for a lot of people, they may be bringing assumptions over from languages where assignment is a statement. That doesn't make them correct.

> required an unintuitive implementation

To some people, sure. To others, it is not unintuitive. It's very regular, and people who get used to "everything is an expression" languages tend to prefer it, I've found.

2 comments

> ...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 an "everything is an expression" language and it has return, and idiomatically it's used identically to Rust: for early returns.

It is of course not statically typed.

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.
> people who get used to "everything is an expression" languages tend to prefer it, I've found

I.e., if we bias our sample to the data points proving our point then our point is proven. It's like that quip about how every car insurance company can simultaneously claim "people who switched saved hundreds of dollars in average."

I also like "everything is an expression" languages, but I don't think that's a fantastic argument.

The original claim that the was responding to in this thread was that `return` as an expression didn't fit in well with Rust, and he said that it did. He also cited how far more things in Rust are expressions than statements, so it stands to reason that people who program in Rust are familiar with those styles of language. It sounds like you're arguing that it makes more sense to judge whether return makes sense as an expression in Rust based on the expectations of people who aren't as familiar with expression-based languages (and therefore aren't super familiar in Rust), which doesn't make a ton of sense to me.