6 ms·

Speaking from a Rust-perspective, having semicolons at the end of statements makes perfect sense and is a brilliant design decision. Note that I said 'statemen

Speaking from a Rust-perspective, having semicolons at the end of statements makes perfect sense and is a brilliant design decision. Note that I said 'statements', not 'expressions'. A lot of the confusion here (and maybe yours, too) stems from this difference. In Rust, (almost) everything is an expression by default, and you turn it into a statement by adding a semicolon. This allows you (and the type checker) to very neatly distinguish between expressions and statements, which is great. It's a very nice and elegant approach imo.

Spivak 2y ago
Does the difference ever come up in a meaningful way? Is there a syntax that without the trailing semicolon is ambiguous between the two, and the difference changes the behavior?
- masklinn 2y ago
  All the time. A block (in the general sense so that includes function) which ends with an expression will have that expression’s value as its own value (/ return). A `;` converts the trailing expression into a statement, which does not have a value, and thus the block returns `()` (the something representing nothing). Method chaining is also common in Rust, because builders are common, and chains of iterator adapters are common, and chains on monadic structures (option/result) are common, … having every line break implicitly insert a `;` would be horrid.
  - notpushkin 2y ago
    Wait, so this is legal: fn five() -> i32 { 5 } and this isn't? fn five() -> i32 { 5; } I can't tell if I'm amazed or terrified.
    - deleted 2y ago
      [deleted]
    - jihiggins 2y ago
      this is what those end up being, it's pretty straightforward? fn five() -> i32 { return 5; } fn five() -> i32 { 5; return (); } semicolon changes the expression from returning the result of the expression to running the expression and returning the unit type. if you accidentally do that and specified a non-unit-return-type in the function signature, the type checker tells you about it: error[E0308]: mismatched types --> src/main.rs:1:14 | 1 | fn test() -> i32 { | ---- ^^^ expected `i32`, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression 2 | 5; | - help: remove this semicolon to return this value which is also pretty clear about the solution
    - masklinn 2y ago
      Yes. > I can't tell if I'm amazed or terrified. The rule is very simple and obvious, and the compiler will yell at you if you get it wrong. It's also very useful and even critical of how expression-oriented the language is: an `if/else` or a match statement must typecheck, all branches have to have the same type. It's obvious if you're using it as an expression, but it doesn't go away if you're using it for the side-effect (as an imperative conditional/switch) and then things can get more dicey as the expressions in each branch can have different types. `;` solves that by making every branch `()`-valued.
      - notpushkin 2y ago
        Okay, this is really neat design. I went to check whether if..else works in an expression context and it does: fn five() -> i32 { let a = if (true) { 3 } else { 6 }; return a + 2; } Pure fun!
        masklinn 2y ago
        Ya if you want fun match/case also works like that. And though for abs while don’t (they always return ()) `loop` itself does, you can `break` with a value and that’s what comes out the loop.
- jihiggins 2y ago
  let x = { 3 }; let y = { 3; }; assert_eq!(x, 3); assert_eq!(y, ()); i think it'd also mean having to parse whitespace or newlines without something like that?
  - Spivak 2y ago
    Thanks, I hate it. Is there any time where you want to use this? Like if Rust worked like other languages and just figured out if it was an expression or statement are there times where you would need an override? I'm playing around with this in the compiler explorer and I'm now even more confused why you want this. let x = { println!("Don't mind me in the struct definition"); 3 } assert_eq!(x, 3);
    - jihiggins 2y ago
      idk there are a lot of uses for it let dx = { let prev_x = x; x = get_x(); x - prev_x }; often, it's slightly better cpp style scoping blocks if nothing else? there are tons of other little QoL things it enables though, but they're all going to be little ergonomics things that only seem worth it if you've used the language for awhile
      - masklinn 2y ago
        Also common to set up "capture clauses" for lambdas as Rust does not have that in the language, IME most common with threads: spawn({ let a = a.clone(); let b = &b; move || { // do something with the a you cloned and the b you borrowed } })
    - steveklabnik 2y ago
      One of the things going on here is consistency. It's not so much that this ability is specifically put in for some reason. It's just something that falls out of several other things. Rust chose a "curly braces and semicolons" syntax because that's the sort of syntax that is normal in the sorts of PL spaces Rust wants to be used in. I am not sure exactly why being expression-oriented was chosen, but if I had to guess, it would be due to that just generally being considered a better option among many people at the time it was chosen. So okay, you want expressions, and you want semicolons. Therefore, "you separate expressions with semicolons" is a pretty natural outcome. And since we're expression oriented, "a block is an expression that evaluates to the final value" is near tautological. And since it's an expression, it can go anywhere an expression can go. Not being able to do this would mean creating specific restrictions against it, and then having to memorize when things don't follow the usual rules. That's more complicated than just letting expressions be expressions. (also your let is missing a semicolon)
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
Varriount 2y ago
Yes, but: - Is having everything be an expression by default a good design choice? A not uncommon idea in programming language design is that certain language constructs (for example, variable assignments) are better off as only statements, as their potential for confusion outweighs their usefulness. - Why should the burden of additional syntax be placed on the most common scenario? Statements (or the desire for statement-like behavior) tend to be far more common than lone expressions. Why not require lone expressions to be specially marked, rather than statements? - Do the benefits of this approach outweigh its costs? Is elegance a desirable trait, and what is its importance relative to other values, such as clarity (how accurately and easily is the writer's intention conveyed to readers) and user experience (what is the potential for this syntax to be forgotten or misused). Personally, I much prefer the design Go uses (where semicolons are implicitly added at the end of newlines following an identifier, numeric or string literal, keyword, or operator).

Spivak 2y ago

Does the difference ever come up in a meaningful way? Is there a syntax that without the trailing semicolon is ambiguous between the two, and the difference changes the behavior?

masklinn 2y ago
All the time. A block (in the general sense so that includes function) which ends with an expression will have that expression’s value as its own value (/ return). A `;` converts the trailing expression into a statement, which does not have a value, and thus the block returns `()` (the something representing nothing). Method chaining is also common in Rust, because builders are common, and chains of iterator adapters are common, and chains on monadic structures (option/result) are common, … having every line break implicitly insert a `;` would be horrid.
- notpushkin 2y ago
  Wait, so this is legal: fn five() -> i32 { 5 } and this isn't? fn five() -> i32 { 5; } I can't tell if I'm amazed or terrified.
  - deleted 2y ago
    [deleted]
  - jihiggins 2y ago
    this is what those end up being, it's pretty straightforward? fn five() -> i32 { return 5; } fn five() -> i32 { 5; return (); } semicolon changes the expression from returning the result of the expression to running the expression and returning the unit type. if you accidentally do that and specified a non-unit-return-type in the function signature, the type checker tells you about it: error[E0308]: mismatched types --> src/main.rs:1:14 | 1 | fn test() -> i32 { | ---- ^^^ expected `i32`, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression 2 | 5; | - help: remove this semicolon to return this value which is also pretty clear about the solution
  - masklinn 2y ago
    Yes. > I can't tell if I'm amazed or terrified. The rule is very simple and obvious, and the compiler will yell at you if you get it wrong. It's also very useful and even critical of how expression-oriented the language is: an `if/else` or a match statement must typecheck, all branches have to have the same type. It's obvious if you're using it as an expression, but it doesn't go away if you're using it for the side-effect (as an imperative conditional/switch) and then things can get more dicey as the expressions in each branch can have different types. `;` solves that by making every branch `()`-valued.
    - notpushkin 2y ago
      Okay, this is really neat design. I went to check whether if..else works in an expression context and it does: fn five() -> i32 { let a = if (true) { 3 } else { 6 }; return a + 2; } Pure fun!
      - masklinn 2y ago
        Ya if you want fun match/case also works like that. And though for abs while don’t (they always return ()) `loop` itself does, you can `break` with a value and that’s what comes out the loop.
jihiggins 2y ago
let x = { 3 }; let y = { 3; }; assert_eq!(x, 3); assert_eq!(y, ()); i think it'd also mean having to parse whitespace or newlines without something like that?
- Spivak 2y ago
  Thanks, I hate it. Is there any time where you want to use this? Like if Rust worked like other languages and just figured out if it was an expression or statement are there times where you would need an override? I'm playing around with this in the compiler explorer and I'm now even more confused why you want this. let x = { println!("Don't mind me in the struct definition"); 3 } assert_eq!(x, 3);
  - jihiggins 2y ago
    idk there are a lot of uses for it let dx = { let prev_x = x; x = get_x(); x - prev_x }; often, it's slightly better cpp style scoping blocks if nothing else? there are tons of other little QoL things it enables though, but they're all going to be little ergonomics things that only seem worth it if you've used the language for awhile
    - masklinn 2y ago
      Also common to set up "capture clauses" for lambdas as Rust does not have that in the language, IME most common with threads: spawn({ let a = a.clone(); let b = &b; move || { // do something with the a you cloned and the b you borrowed } })
  - steveklabnik 2y ago
    One of the things going on here is consistency. It's not so much that this ability is specifically put in for some reason. It's just something that falls out of several other things. Rust chose a "curly braces and semicolons" syntax because that's the sort of syntax that is normal in the sorts of PL spaces Rust wants to be used in. I am not sure exactly why being expression-oriented was chosen, but if I had to guess, it would be due to that just generally being considered a better option among many people at the time it was chosen. So okay, you want expressions, and you want semicolons. Therefore, "you separate expressions with semicolons" is a pretty natural outcome. And since we're expression oriented, "a block is an expression that evaluates to the final value" is near tautological. And since it's an expression, it can go anywhere an expression can go. Not being able to do this would mean creating specific restrictions against it, and then having to memorize when things don't follow the usual rules. That's more complicated than just letting expressions be expressions. (also your let is missing a semicolon)

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

Varriount 2y ago

Yes, but: - Is having everything be an expression by default a good design choice? A not uncommon idea in programming language design is that certain language constructs (for example, variable assignments) are better off as only statements, as their potential for confusion outweighs their usefulness. - Why should the burden of additional syntax be placed on the most common scenario? Statements (or the desire for statement-like behavior) tend to be far more common than lone expressions. Why not require lone expressions to be specially marked, rather than statements? - Do the benefits of this approach outweigh its costs? Is elegance a desirable trait, and what is its importance relative to other values, such as clarity (how accurately and easily is the writer's intention conveyed to readers) and user experience (what is the potential for this syntax to be forgotten or misused). Personally, I much prefer the design Go uses (where semicolons are implicitly added at the end of newlines following an identifier, numeric or string literal, keyword, or operator).