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.
