Tracking Issue for const Result methods

[jhpratt]

Feature gate: #![feature(const_result)]

This is a tracking issue for making a number of Result methods const fn.

Public API

NB: Many of these methods will need ~const Drop. They're omitted here for brevity.

impl<T, E> Result<T, E> {
    pub const fn as_mut(&mut self) -> Result<&mut T, &mut E>;
}

impl<T, E> Result<Option<T>, E> {
    pub const fn transpose(self) -> Option<Result<T, E>>;
}

impl<T, E> Result<&T, E> {
    pub const fn copied(self) -> Result<T, E>
    where
        T: Copy;
}

impl<T, E> Result<&mut T, E> {
    pub const fn copied(self) -> Result<T, E>
    where
        T: Copy;
}

Note some things are missing compared with Option (#67441):

• unwrap, expect: drops the error, so cannot be done in const.
• flatten: is not stable yet on Result, even outside const.
• take, replace: does not exist on Result.

See also #57563.

Please post a comment in this issue if you're submitting a PR that changes any of the above!

[netsutetsu]

Why aren't there unwrap_unchecked and unwrap_err_unchecked while Option::unwrap_unchecked() is going to be const in #91930?

[jhpratt]

The methods probably didn't exist when this issue was created. I'll add them when I'm on my laptop.

[netsutetsu]

Could you also add contains, contains_err (introduced in #62358), inspect, inspect_err (introduced in #91345), flatten (introduced in #70142), copied, cloned and iter since Option::contains(), Option::inspect(), Option::flatten(), Option::copied(), Option::cloned() and Option::iter() will be const in #91930, #67441 and #91582?

[jhpratt]

Going through the full list now. I'm only going to be adding methods that are already stable, as the unstable methods are tracked in their associated issues.

[pitaj]

@jhpratt PR #104407 for Result::{map, map_or, map_or_else, map_err, as_deref, as_deref_mut, unwrap_or_default, and_then, or_else, unwrap_or_else, unwrap_unchecked, unwrap_err_unchecked, copied, cloned}

[jhpratt]

@pitaj Thanks. I was already subscribed to the issue, but there's nothing actionable in this tracking issue at the moment.

[Pzixel]

What happened to const_result? About a week ago everything was fine and now feature gate is gone and with it some of my code started to fail. I understand it's nightly and things change but I don't see any motivation/discussion why this happened. Does anyone have any insights?

[c410-f3r]

#110393

Looks like any stuff related to constant bounds will take a considerable amount of time to be resolved.

[RalfJung]

Yeah, most of the things that were in this feature gate unfortunately depend on "const traits" and that's still very experimental.

The remaining methods listed here, however, can probably be stabilized fairly soon. :)

[RalfJung]

@rust-lang/libs-api matching Option, some long-stable Result methods can be const-stabilized now as well. :)
However, sadly it's much fewer than with Option, because methods like unwrap would drop the error and we can't drop things in const fn.

[dtolnay]

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.