However, stabilizing `?` is not blocked on any particular work as much as on the relevant team deciding its a good feature without big bugs that they are happy to see made permanent. Given that a minority of the community opposes `?` vehemently, this process will probably move slowly.
Personally, I opt into question mark in all of my nightly code and I absolutely love it. I had a case last night actually where I really wanted `catch` also.
Well for one, there's a huuuuuge unresolved question: should it work for Option as well as Result? If we stabilized just the Result version, would we lock out the possibility of extending it in the future?
Just in general, it is a huge, and widely debated new feature that only landed recently. It needs more time before we can consider stabilizing it. One of the longest-running and most-commented RFCs in Rust history deserves to not just be made stable as quickly as possible, but to take it slow and make sure we get it right.
I've read the RFC and quite a bit of the surrounding debate, and I knew that most of it would take longer to stabilize. I just didn't realize that the '?' notation in particular was still under debate.
Why would stabilizing the Result version of '?' lock out the possibility of supporting it on Option or other types in the future?
In any case, I look forward to it whenever it becomes available in a stable release.
Well, because in stabilizing something, you have to declare exactly what is stable, and what the semantics are. "? only works with Result" is not a detailed enough semantic, so you have to dig into details. Is it based on a trait? If so, and the trait gets designed incorrectly, it could cause problems. Is it not based on a trait? Now the language needs to know about Result, specifically.
> I just didn't realize that the '?' notation in particular was still under debate.
Well, we have never had a case yet where an accepted RFC failed to end up actually being stable. We have had some RFCs that have had final details take a very long time. But in theory, it could happen.
Uh... That doesn't seem true at all? Unstable stuff gets deprecated all the time (the libs team basically defaults to delete-everything), and I assure you that some of that stuff was accepted in an RFC. There's also the case that the design is significantly changed in inplementation or as an ammendment RFC (e.g. maybe ? becomes ?? or ?! to let ? be used like swift/c#). Entry API is the most obvious case of this kind of change happening to me. BTree range api will literally never be stabilized as-is. The defaults-affect-inference design has been dead in the water for months, for an example from the lang team.
So, when I think about this, all the stuff that was unstable and therefore deprecated landed pre 1.0, but I _guess_ that was still RFC'd? Maybe my timeline is a bit off here.
I guess, my ultimate point is this: we have not made very many significant language changes in this first year of Rust. Now, we're starting to. It's new territory. Things can happen that may not have happened before, including these significant new features not actually landing.
> Why would stabilizing the Result version of '?' lock out the possibility of supporting it on Option or other types in the future?
It wouldn't necessarily but it could be done in a way where it does lock it out. For example, `?` could be implemented by defining an attribute which is applied to Result in libcore. If that attribute were stabilized, it would make it hard to migrate to using a trait to define the behavior of `?`, because you've made a guarantee that this attribute makes a type use `?`.
All of this has been avoided though, I think. Stabilization or deprecation of `?` is pretty much a political issue now and not a technical one (and I don't mean that the question is frivolous, just that its about what people want now).
There's still the Carrier trait which has unresolved technical questions, and the catch construct I don't think even has a PR.
