Different people has different priority, but I will say mine, and let you guys discuss:
async fn in trait
let chain,
generator,
Are we going to have a ?. operator like in c# (any other shape) at all? I saw it came out again and again in the forum, which means people really want it.
and apparently bug fixes.
All the other small apis here and there is really not that important, as we can always come up of our own if we really need it.
It seems like take forever (I mean YEARS................).
People want it simply because it's available in other languages long time ago, and very handy, We DO understand it's a different challenge in RUST. But let's discuss it and make a decision. Maybe they are simply impossible in RUST.
RUST is a great language, but it seems moving too slow.
?. is already valid syntax and uses the try operator, which returns from the function rather than doing the equivalent of and_then like in C#. What you want instead are try { } blocks (e.g. a?.b() in C# would become try { a?.b() } with try blocks in Rust). The current unsolved problem with try blocks is type inference of the error type.
It will be worse if unfinished features are released too soon. Also, arguably some people think it moves too fast.
You're free to help solving blocking issues if you're eager for new features.
You can check status of if-let-chains at https://github.com/rust-lang/rust/issues/53667 (also look at the last 3 comments since some issues are not reported in the first one). This is not a question of whether we want this feature or not (most people do!) but of fixing the last bugs (which are pretty tricky!). If you want to invest some effort for stabilizing if-let-chains you could focus on help fixing those bugs (by either opening PRs to fix them, reviewing existing ones or testing the feature/open PRs) and summarize the current status of the feaure.
It's out of my league to attack compiler problems.
Do you think let-chain feature will be removed in future? If not, I can start to use the nightly build.
Also, I am wondering if we can change the mindset a little bit. i.e., release some half baked feature.
Take let-chain, for instance, we can release the feature now, with a compilation error message that certain "corner use case" is not supported. This probably covers 99% use cases.
This is how most projects are done. You can't expect everything is perfect. GOD knows that corner use case may never be fixed, it may not be even possible to fix. With all the type inference, life time analysis, really, I accept the fact that something is simply impossible. We just conservatively enable some feature to improve our productivity.
Everyone had to start somewhere. Just try to tackle the smaller problems first and as you start gaining knowledge you can shift to more complex/challenging ones. For example just helping test some feature is something everyone should be able to do.
No, Rust highly values backward compatibility and releasing half backed features while later fixing them will likely break it. This can work only if you release a strict and well-tested subset of the feature, but that's not always possible.
Not every corner case is easily detectable. In case of let-chains detecting it is not that different than fixing it (and also is not that corner of a case).
This reasoning works as long as you have few features. The more features you have the most corner cases the users will have to learn, which in turn will make your language much more difficult to learn. This leads to either a language as complex as C++ or to breaking changes which split the ecosystem.
As for let chains, the implementation used to be straight up wrong, which causes crashes and wrong behavior. Fixing that meant breaking it, which was then done. We are still not entirely confident that the implementation is correct and there are still cases that cause compiler crashes I think. Once we're confident that it actually works, it can be stabilized.
If you want to use half-baked features, use nightly!
There will be an explicit question about the priority of stabilizing specific features (or not stabilizing anything at all!) in the Annual Rust survey, which should come out in a few weeks. So we might get some more data on this soon.
There was a somewhat recent blog post from @nikomatsakis about stabilization that seems somewhat relevant. In short, he proposes splitting the current three-way split of incomplete/unstable/stable further, e.g. into (naming arbitrary and mine):
experimental: anything goes, may be arbitrarily wrong
unstable: usable, but may break arbitrarily
preview: mostly stable but has potential for small breaking changes (e.g. a rename or edge case functionality, but probably won't be removed)
stable: available without global opt-in, may be lacking in docs and/or error messages and/or tooling support
release: stable and with great docs/tooling support
with the goal being to make things more available sooner. The main thesis being that we have historically conflated both "truly unstable" with "conservatively unstable" and "stable" with "polished," and that distinguishing those tiers could help in making more things available sooner.
I'm even fine with something being removed or changed, as long as it is being replaced with something equivalent and it won't require a complete rewrite/rearchitectue of my code. And that there is a long enough deprecation window that I don't have to hold off updating rustc due to one of my dependencies still being on the old version of the not-quite-stable feature.
The big issue is what exactly those tiers actually do, of course: I think a tier that lets crates opt into unstable-ish features on stable would be pretty nice, as would bring able to use some features on beta (since it currently doesn't seem too useful?). But I haven't really spent much time thinking about this.
Do you think let-chain feature will be removed in future? If not, I can start to use the nightly build.
Also, I am wondering if we can change the mindset a little bit. i.e., release some half baked feature.