- Can we end without using a semicolon, like In modern programming languages golang or Python never have semicolons ,That might get more people to use rust.
Can we instead please change things so a semicolon is required after the last expression in a block. The block still returns that expression's value. You have to write (); as the last expression if you need to force a block's value to be ().
1 Like
Strongly opposed on both points. Semicolon present means "this is a statement that doesn't resolve to a value", no semicolon means "the surrounding scope resolves to the value of this expression"
8 Likes
No: https://lang-team.rust-lang.org/frequently-requested-changes.html#fundamental-changes-to-rust-syntax
24 Likes
We could have another language, let's call it Gust, that is just a reskin of Rust like Coffeescript was a reskin of Javascript
The Gust creator would be allowed to make different syntax choices in Gust, but just compile to Rust, in such a way that it's essentially the same language (and the same ecosystem etc)
Programs written in Gust would be compatible with rustc and cargo by providing a build.rs one liner that transpiled Gust to Rust. This would enable Rust programs to have Gust dependencies and Gust programs to have Rust dependencies, in such a way to not matter whether some crate is written in Rust or Gust
And maybe fork rust-analyzer to support Gust language, etc etc
Essentially Gust would work like another Rust edition, but not controlled by the Rust project
... Okay I don't know how feasible would be that. Tooling support would require a lot of work and constant upkeep, but perhaps a proof of concept wouldn't take too much time
My point is that if there's enough demand for something there is always a way forward, even if it seems that something is plain impossible. Heck, even a behemot language like C++ began just as a transpiler to C
2 Likes
That is too much weight to put on a single punctuator whose presence or absence is easy to miss when reading code quickly.
I am not seriously proposing a change here. I would make this change if I were building a Rust-like language from scratch, but obviously it's a non-starter for Rust as it is, given the volume of code that would be broken. I brought it up to make a meta-point, that it is possible to make a serious argument for the exact opposite change from what @rona suggested.
I've been regularly tempted to design such a thing myself; if I ever do it for real, I'll probably call it "Patina". My list of syntactic papercuts, besides the above, includes
- unary
*should be a postfix operator - The operator precedence hierarchy should be much flatter, in particular you should be required to parenthesize
a || b && c - Single-expression lambdas should have an explicit right delimiter
'should not be used for both lifetimes and character literals
- Use
=instead of:inside struct initialization
4 Likes
In the immortal words of Tim Chevalier:
Please read:
https://www.rust-lang.org/policies/code-of-conduct
In particular, the code of conduct section:
"Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works."
Please remember that the decisions that you're just learning about now are ones that other people have put a ton of time, thought, and effort into. Assume that if something strikes you the wrong way, it's probably not because no one else has thought about it, but because it's the result of a trade-off. As this point in the design of Rust, we're unlikely to make any major syntax changes. The focuses right now are on completing the few remaining features that aren't done, library development, and performance.
3 Likes