Actually I think that my RFC is going to propose changing the name of future Rust editions to Rust++. To distinguish it from Rust. That way us mere mortals will know to stay away from it, like C++.
Only joking.... I hope.
1 Like
I realize that many things which help with prototyping go against Rust's usual focus on correctness.
When prototyping I'm OK with lots of implicit behaviors that move details out of the way. But these same features are problematic when debugging or verifying correctness of the code.
Rust doesn't like mess, but prototypes intentionally permit mess.
Maybe Rust could have an attribute like:
#![allow(quick'n'dirty)]
3 Likes
You are making me nervous.
But you have hit on something that occurred to me the other day. That could save Rust from the dreaded feature creep and the endless addition of ever more incomprehensible features.
What if, I thought, all those new features people suggest and will suggest in the future were fundamentally impossible to make work in Rust thanks to it's rigid principles regarding types, alisasing and correctness in general. Then, as long as the Rust devs held their ground and adhered to their principles and core values, Rust would be safe from the C++ style road to ruin.
There's no need to be so cynical about feature requests on Rust forums. The simple reality is that the number of forum posts people make suggesting some feature or other has at most an extremely loose connection to whether the Rust project as a whole takes action.
The overwhelming majority of the time, such suggestions are either:
- a good idea, but one that's already being worked on in a bunch of other places and the poster just failed to google it, or
- a good idea that simply isn't a high priority compared to everything else that we're already working on, or
- a good idea that doesn't involve any language changes and can be done entirely in library code
- a not-so-good idea, either due to a fundamental misunderstanding the Rust language, or their own personal priorities being too different from Rust's priorities, or the poster failing to think through crucial parts of their own idea
And such threads are typically full of veterans explaining why the idea falls into one of these buckets. That includes most of this thread.
More concretely, it's worth noting that things like #![allow(non_standard_style)] have been around for ages, so #![allow(quick'n'dirty)] isn't exactly unprecedented. I doubt it's the right move here, but we'd have to spell out the idea in more detail to discuss that, and it already seems clear that the right move involves finishing a bunch of features that everyone already agrees we need, so there's not much point at the moment.
2 Likes
But Rust doesn't have a ++ operator, so you should call it Rust += 1 
1 Like
Good point.
Or perhaps Rust<'b>. To be more idiomatic.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.