8 ms·

Well, Rust barely has statements [1]. Nearly everything in Rust is an expression, and AFAIK statements /are/ essentially expressions that yield `()` [2]. [1]:

Well, Rust barely has statements [1]. Nearly everything in Rust is an expression, and AFAIK statements /are/ essentially expressions that yield `()` [2]. [1]: https://doc.rust-lang.org/reference/statements.html https://doc.rust-lang.org/reference/statements.html [2]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=12aacef98d63cb28ec12b0ae96308619 https://play.rust-lang.org/?version=stable&mode=debug&editio...

steveklabnik 1y ago
> AFAIK statements /are/ essentially expressions that yield `()` This isn't true. The inverse is true, "expression statements" can turn an expression into a statement. What you're seeing in the playground is just how blocks are defined[1]: > The syntax for a block is {, then any inner attributes, then any number of statements, then an optional expression, called the final operand, and finally a }. In this case, you have one statement, and no optional expression. And so: > The type of a block is the type of the final operand, or () if the final operand is omitted. So that's how this works. Now, that being said, I don't think it's too terrible of a mental model to think of this situation in that way. But if we're getting into nitty-gritty details, that's not actually how it works. 1. https://doc.rust-lang.org/stable/reference/expressions/block-expr.html https://doc.rust-lang.org/stable/reference/expressions/block...
- int_19h 1y ago
  Out of curiosity, why does Rust make the expression/statement distinction? Does it interact with the borrow checker somehow?
  - steveklabnik 1y ago
    > Does it interact with the borrow checker somehow? Nope. The borrow checker cares about the control flow graph, expression vs statement doesn't matter. > why does Rust make the expression/statement distinction? I am not 100% sure. If I had to guess, older Rust was much less expression oriented, and then, over time, got moreso. But also, I think it kinda just makes sense in general for the kind of language Rust is. Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects. Whereas in Rust, 95% of statements are declarations, and of those 95%, the only ones you really use in a normal execution context are let statements. The rest are stuff like "declaring functions" and "declaring structs" and those don't really get evaluated in a language like Rust. let being a statement is nice because it means it can only happen at the "top level" of a block, and not say, inside a loop condition.
    - int_19h 1y ago
      > Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects. In the context of ML, I think it's a more useful baseline. So declarations are still declarations, but e.g. ; is just a sequential evaluation operator. > let being a statement is nice because it means it can only happen at the "top level" of a block, and not say, inside a loop condition. I would argue that it's actually a downside - it means that a loop condition cannot have common subexpressions (that nevertheless need to be evaluated on every iteration) factored out.
      - steveklabnik 1y ago
        I guess if you required ; after all of them, sure. Rust doesn’t, so I didn’t think of that. I’ve always found code that does this to be more complicated to read and understand than rewriting it in a different way. YMMV, of course.
    - dragonwriter 1y ago
      > Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects. That's not so much “everything is an expression” as “everything is at runtime”.
      - steveklabnik 1y ago
        Eh that’s fair.
- needlesslygrim 1y ago
  Oh I see. I assumed being able to explicitly yield unit meant statements were essentially just syntax sugar for unit. Thanks for the correction.
  - steveklabnik 1y ago
    No problem! This really only comes up in very edge cases anyway, which is partially why I don’t think it’s the worst mental model for most people. As long as you know that you can’t put let in expression position, that’s really the only place it goes wrong. Most people who haven’t used a language like Ruby would even think of items as being expressions in the first place.

steveklabnik 1y ago

> AFAIK statements /are/ essentially expressions that yield `()` This isn't true. The inverse is true, "expression statements" can turn an expression into a statement. What you're seeing in the playground is just how blocks are defined[1]: > The syntax for a block is {, then any inner attributes, then any number of statements, then an optional expression, called the final operand, and finally a }. In this case, you have one statement, and no optional expression. And so: > The type of a block is the type of the final operand, or () if the final operand is omitted. So that's how this works. Now, that being said, I don't think it's too terrible of a mental model to think of this situation in that way. But if we're getting into nitty-gritty details, that's not actually how it works. 1. https://doc.rust-lang.org/stable/reference/expressions/block-expr.html https://doc.rust-lang.org/stable/reference/expressions/block...

int_19h 1y ago
Out of curiosity, why does Rust make the expression/statement distinction? Does it interact with the borrow checker somehow?
- steveklabnik 1y ago
  > Does it interact with the borrow checker somehow? Nope. The borrow checker cares about the control flow graph, expression vs statement doesn't matter. > why does Rust make the expression/statement distinction? I am not 100% sure. If I had to guess, older Rust was much less expression oriented, and then, over time, got moreso. But also, I think it kinda just makes sense in general for the kind of language Rust is. Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects. Whereas in Rust, 95% of statements are declarations, and of those 95%, the only ones you really use in a normal execution context are let statements. The rest are stuff like "declaring functions" and "declaring structs" and those don't really get evaluated in a language like Rust. let being a statement is nice because it means it can only happen at the "top level" of a block, and not say, inside a loop condition.
  - int_19h 1y ago
    > Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects. In the context of ML, I think it's a more useful baseline. So declarations are still declarations, but e.g. ; is just a sequential evaluation operator. > let being a statement is nice because it means it can only happen at the "top level" of a block, and not say, inside a loop condition. I would argue that it's actually a downside - it means that a loop condition cannot have common subexpressions (that nevertheless need to be evaluated on every iteration) factored out.
    - steveklabnik 1y ago
      I guess if you required ; after all of them, sure. Rust doesn’t, so I didn’t think of that. I’ve always found code that does this to be more complicated to read and understand than rewriting it in a different way. YMMV, of course.
  - dragonwriter 1y ago
    > Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects. That's not so much “everything is an expression” as “everything is at runtime”.
    - steveklabnik 1y ago
      Eh that’s fair.
needlesslygrim 1y ago
Oh I see. I assumed being able to explicitly yield unit meant statements were essentially just syntax sugar for unit. Thanks for the correction.
- steveklabnik 1y ago
  No problem! This really only comes up in very edge cases anyway, which is partially why I don’t think it’s the worst mental model for most people. As long as you know that you can’t put let in expression position, that’s really the only place it goes wrong. Most people who haven’t used a language like Ruby would even think of items as being expressions in the first place.