The problem is that "implicit return" is the wrong mental framing. Expressions evaluate to a value. That's true in every language that supports expressions. Some just go more all-in on expressions than others do. This is important because
> Is it common to use the conversational nature of expressions and implicit returns?
I have found that most people who do not have experience in expression-oriented languages end up confusing themselves because of it. They'll ask how you're supposed to know where a function returns, when a return can just happen anywhere. But it can't! That's not how it works!
Like any new concept, it can take some time to wrap your head around how it influences how you write code. But I think that the end result is far better. Compare this lambda in C++:
[](int n, int x) { return n < x; }
to this closure in Rust:
|n| { n < x }
there are multiple reasons why the Rust is shorter here, and you can argue some of them are better or worse, but not needing the return and semicolon here makes it easier to read, at least for me.
But I think that sometimes people who learn about "implicit returns" write things like iterator chains, that take closures, not even realizing that they're using "implicit returns" in that circumstance. It just feels natural, especially in simple cases like this.
But also, I've been mainly writing in expression-oriented languages for the majority of my professional career, so of course it makes sense to me.
I think that's a great argument to consider when framing this concept to someone the first time. Avoid the `implicit return` language altogether. Instead focus on the expressions. `Implicit` triggers mental responses like "I prefer explicit over implicit" but you're right, that's just a side effect of what's really going on here.
Thank you, and yeah, I didn't even think about that aspect of it too, but you're right. I think the reason it's a popular formulation of the semantic is that it's kind of like, trying to describe it from a statement-oriented viewpoint, and there's certainly value in trying to help bridge an understanding gap by relating it to things that you know. But I worry that it either gives the wrong impression (heck I would hate true "implicit returns" too!) or that people tend to stop there as opposed to truly making the mental shift. This stuff is hard!
> Is it common to use the conversational nature of expressions and implicit returns?
I have found that most people who do not have experience in expression-oriented languages end up confusing themselves because of it. They'll ask how you're supposed to know where a function returns, when a return can just happen anywhere. But it can't! That's not how it works!
Like any new concept, it can take some time to wrap your head around how it influences how you write code. But I think that the end result is far better. Compare this lambda in C++:
to this closure in Rust: there are multiple reasons why the Rust is shorter here, and you can argue some of them are better or worse, but not needing the return and semicolon here makes it easier to read, at least for me.But I think that sometimes people who learn about "implicit returns" write things like iterator chains, that take closures, not even realizing that they're using "implicit returns" in that circumstance. It just feels natural, especially in simple cases like this.
But also, I've been mainly writing in expression-oriented languages for the majority of my professional career, so of course it makes sense to me.