Tracking issue for Option::expect_none(msg) and unwrap_none()

[cuviper]

impl<T: fmt::Debug> Option<T> {
    pub fn expect_none(self, msg: &str);
    pub fn unwrap_none(self);
}

Steps:

• Merge the implementation (Add Option::expect_none(msg) and unwrap_none() #62596)
• Stabilization PR
• Update the must_use message on is_none (per Add messages to Option's and Result's must_use annotation for is_* #62431 (review))

[jfrimmel]

Small and very minor documentation note:

If this has landed, we should adjust the #[must_use] attribute of Option::is_none() to keep symmetry with is_some().

Currently the hint on is_some() is "if you intended to assert that this has a value, consider .unwrap() instead", whereas the one for is_none() is longer and more verbose: "if you intended to assert that this doesn't have a value, consider .and_then(|| panic!(msg)) instead".
Once this methods are stable we should change the latter to "if you intended to assert that this doesn't have a value, consider .unwrap_none()".

[cuviper]

@jfrimmel yes, that's the third item in the checklist here.

[jfrimmel]

Oh, excuse me. Note to myself: read the issues completely before commenting. Sorry again.

[cuviper]

I guess it could use more in-repo callers? I do see that rustc_middle and rustc_mir are using expect_none, at least. Grepping for assert.*is_none shows a lot more possibilities, but maybe some of those would not like the added code to Debug the value in the panic message.

[aclysma]

I'd love to see this go to stable.. I'm having to do this:

let old_value = self.values.insert(key, value);
assert!(old_value.is_none());

And I'd much rather do

self.values.insert(key, value).unwrap_none();

[dtolnay]

In the stabilization PR it was raised that &self may be more appropriate and flexible in these signatures than self. Do potential users here have a preference for either?

[RustyYato]

You can use as_ref if you need a reference. Also, we should be consistent between our functions (Option::unwrap).