Tracking Issue for constifying `Result` methods that drop values

[clarfonthey]

Feature gate: #![feature(const_result_drop)]

Public API

This is a tracking issue for the const_result_drop feature, which includes constness for the following methods:

impl<T, E> Result<T, E> {
    // will drop error
    pub const fn ok(self) -> Option<T>
    where
        E: ~const Drop;

    // will drop ok
    pub const fn err(self) -> Option<E>
    where
        T: ~const Drop;

    // will drop error or the argument
    pub const fn and<U>(self, res: Result<U, E>) -> Result<U, E>
    where
        T: ~const Drop,
        U: ~const Drop,
        E: ~const Drop;
    
    // will drop ok or the argument
    pub const fn or<F>(self, res: Result<T, F>) -> Result<T, F>
    where
        T: ~const Drop,
        E: ~const Drop,
        F: ~const Drop;

    // will drop error or the argument
    pub const fn unwrap_or(self, default: T) -> T
    where
        T: ~const Drop,
        E: ~const Drop;
}

Note that these depend on the semantics for ~const Drop, which is (probably) tracked in #67792.

Steps / History

• Implementation: Add Result::{ok, err, and, or, unwrap_or} as const #92385
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[clarfonthey]

Turns out you actually can't make these const, at least for now. So, closing.

[clarfonthey]

Reopened now that I've found a proper way to do this. Linked the tracking issue for ~const since this depends on the semantics of ~const Drop.

[jhpratt]

Duplicate of #82814?

[clarfonthey]

That appears to be a meta tracking issue, this is specifically for these methods.

[jhpratt]

At least when I created it, it was not intended to be a meta issue. Result::as_mut, Result::transpose, and Result::flatten point directly to that as their tracking issue.