Rust: 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:

• [x] Merge the implementation (#62596)
• [ ] Stabilization PR
• [ ] Update the must_use message on is_none (per https://github.com/rust-lang/rust/pull/62431#pullrequestreview-258576936)

[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.

[vorot93]

Anything out there that blocks stabilization?

[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).

[aclysma]

I'd like to see unwrap_none be completely parallel to unwrap_err. Result has unwrap(self) and unwrap_err(self), so I think Some should likewise have unwrap(self) and unwrap_none(self).