I can understand braces (to an extent...). What really confuses me are new languages that still require semicolons at the end of expressions/statements.
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.
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.
fn five() -> i32 {
5
}
fn five() -> i32 {
5;
}
fn five() -> i32 {
return 5;
}
fn five() -> i32 {
5;
return ();
}
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
> 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.
fn five() -> i32 {
let a = if (true) { 3 } else { 6 };
return a + 2;
}
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.
let x = {
3
};
let y = {
3;
};
assert_eq!(x, 3);
assert_eq!(y, ());
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); let dx = {
let prev_x = x;
x = get_x();
x - prev_x
};
spawn({
let a = a.clone();
let b = &b;
move || {
// do something with the a you cloned and the b you borrowed
}
})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)
It works with RAII to create a temporally isolated resource scope, think context managers / using / try-with-resource; it provides a scratch space where you limit collisions with the rest of the function and avoid the risk of mis-reuse of those values; and before non-lexical lifetimes it was critical to limit borrow durations. It's also routinely used in combination with closures, to prepare their capture. Similar to C++ capture clauses, but without special syntax.
It's essentially a micro-namespace inside the function.
You can use this to e.g. acquire a Mutex guard, move/clone something out of the mutex, and ensure it gets dropped as quickly as possible.
let x = {
let items = vec![1, 2, 3];
items[1] // copied out of the vec since usize implements the Copy trait
// compiler inserts drop(items) here
};
// items is no longer valid
assert_eq!(2, x);
let condition = true;
let x = if condition {
println!("condition is true");
5
} else {
println!("condition is false");
10
};
assert_eq!(5, x);
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).
Plus I don't think I've ever seen a case where semicolons made the code harder to read (or write).
If you follow those rules, you will see that this:
if true;
{
fmt.Println()
}
else
{
fmt.Println()
}
if true;
{
fmt.Println();
};
else;
{
fmt.Println();
};
It used to be that the compiler gave some pretty confusing errors about semi-colons on this, but it seems that's been improved now.
JavaScript has similar semi-colon insertion by the way, but with some different (more confusing) rules.
foo
.bar()
foo.
bar()
You can endlessly argue what location is better for the ".", but it really doesn't really matter. Regardless, you don't really need to do parser tricks.
It also looks like shit, because now you have to check the end of the previous line to know whether it's a method call or a function call which was indented in incorrectly.
I do see what you mean, of course, and am aware of the arguments but I've never found lack of non-whitespace expression terminator even remotely confusing. I can clearly see indentation in my periphery signalling that it's multi-line. I can also say that in ~13 of using exclusively using semicolon-less languages, I've never had or even heard of a problem caused by someone misunderstanding where an expression ends.
Anyway, this is getting pretty bikesheddy, lol but ya, to each their own, obviously.