Repository navigation
Tracking Issue for constifying Result methods that drop values #92384
Description
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.
Activity
clarfonthey commentedon Dec 29, 2021
Turns out you actually can't make these const, at least for now. So, closing.
clarfonthey commentedon Dec 29, 2021
Reopened now that I've found a proper way to do this. Linked the tracking issue for
~constsince this depends on the semantics of~const Drop.[-]Tracking Issue for `const_result_option`[/-][+]Tracking Issue for constifying `Result` methods that drop values[/+]Rollup merge of rust-lang#92385 - clarfonthey:const_option, r=fee1-dead
Rollup merge of rust-lang#92385 - clarfonthey:const_option, r=fee1-dead
Rollup merge of rust-lang#92385 - clarfonthey:const_option, r=fee1-dead
Rollup merge of rust-lang#92385 - clarfonthey:const_option, r=fee1-dead
jhpratt commentedon Mar 17, 2022
Duplicate of #82814?
clarfonthey commentedon Mar 17, 2022
That appears to be a meta tracking issue, this is specifically for these methods.
jhpratt commentedon Mar 17, 2022
At least when I created it, it was not intended to be a meta issue.
Result::as_mut,Result::transpose, andResult::flattenpoint directly to that as their tracking issue.clarfonthey commentedon Mar 17, 2022
Yes, but for now, these methods point to this one, since they presumably would need their own FCP.
jhpratt commentedon Mar 17, 2022
I figured it would be a partial stabilization of #82814. Not a big deal either way, just wanted to bring it to your attention 🙂
RalfJung commentedon Sep 8, 2024
This got removed by #110393.