I'm submitting 2 language "tidy up" feature suggestions.
The first is to use ! as syntactical sugar for "unwrap()".
The choice of operator is simple.
It means "we're certain this will succeed" (exclamation point - slam it down)
And fits well opposing the ? operator which naturally means "we're not certain" (ie, don't panic on this one).
And it could also be "aligned with" the never operator in a way. "this never supposed to error - terminate if it does"
Though it has a different meaning on option, so maybe this would only be the case for unwrapping a result, not an option.
Rust's preferred manner of handling errors is to propagate them where possible, which is done with ?. Having to write out the longer .unwrap() is a good thing, in my opinion, as it shows a potential panic if you're wrong.
That's based on assumption that .unwrap() is somehow a flaw in the design that needs tidying up. That's not the case: .unwrap() was designed to be obnoxious on purpose, because you shouldn't use it in production code. Instead you should properly handle the errors via error propagation (?), explicit pattern matching, or error combinators.
EDIT: But I do not agree with adding a shorthand for unwrap(). It is good to have to write it (or expect()) out. While I'm fine writing unwrap()/expect(), I also wouldn't want to make it too easy or ergonomic to use. It is certainly something to use with caution.
Just as a historical note: this syntax was tossed around by the lang team prior to the 1.0 release in 2015. There was a consideration of changing the macro syntax (probably to @println instead of println!) to free up ! for this purpose. That wasn't done, and I don't think there's much appetite for this kind of change now.
Even so we have ! fixed for macros, it is still possible to use it for unwrap with a little more burden. The trick is that macros ! must be following an identifier, making it possible to enable writing (exp)! for exp.unwrap(), as well as variable.foo()! etc.
I actually do, because I often ponder offering more negated things like that.
It probably will never pull its weight enough that I'd actually propose it, but my EE brain thinks of "NAND" as one thing, and thus would sometimes like to be able to just write a !& b instead of !(a & b).