Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for constifying Result methods that drop values #92384

Closed
1 of 3 tasks
clarfonthey opened this issue Dec 29, 2021 · 8 comments
Closed
1 of 3 tasks

Tracking Issue for constifying Result methods that drop values #92384

clarfonthey opened this issue Dec 29, 2021 · 8 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-const_trait_impl `#![feature(const_trait_impl)]` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@clarfonthey
Copy link
Contributor

clarfonthey commented Dec 29, 2021

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

Unresolved Questions

  • None yet.
@clarfonthey clarfonthey added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Dec 29, 2021
@clarfonthey
Copy link
Contributor Author

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

@clarfonthey
Copy link
Contributor Author

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.

@clarfonthey clarfonthey changed the title Tracking Issue for const_result_option Tracking Issue for constifying Result methods that drop values Jan 29, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 6, 2022
Add Result::{ok, err, and, or, unwrap_or} as const

Already opened tracking issue rust-lang#92384.

I don't think that this should actually cause any issues as long as the constness is unstable, but we may want to double-check that this doesn't get interpreted as a weird `Drop` bound even for non-const usages.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 8, 2022
Add Result::{ok, err, and, or, unwrap_or} as const

Already opened tracking issue rust-lang#92384.

I don't think that this should actually cause any issues as long as the constness is unstable, but we may want to double-check that this doesn't get interpreted as a weird `Drop` bound even for non-const usages.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Mar 8, 2022
Add Result::{ok, err, and, or, unwrap_or} as const

Already opened tracking issue rust-lang#92384.

I don't think that this should actually cause any issues as long as the constness is unstable, but we may want to double-check that this doesn't get interpreted as a weird `Drop` bound even for non-const usages.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Mar 8, 2022
Add Result::{ok, err, and, or, unwrap_or} as const

Already opened tracking issue rust-lang#92384.

I don't think that this should actually cause any issues as long as the constness is unstable, but we may want to double-check that this doesn't get interpreted as a weird `Drop` bound even for non-const usages.
@jhpratt
Copy link
Member

jhpratt commented Mar 17, 2022

Duplicate of #82814?

@clarfonthey
Copy link
Contributor Author

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

@jhpratt
Copy link
Member

jhpratt commented Mar 17, 2022

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.

@clarfonthey
Copy link
Contributor Author

Yes, but for now, these methods point to this one, since they presumably would need their own FCP.

@jhpratt
Copy link
Member

jhpratt commented 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 🙂

@fee1-dead fee1-dead added the F-const_trait_impl `#![feature(const_trait_impl)]` label Mar 24, 2023
@RalfJung
Copy link
Member

RalfJung commented Sep 8, 2024

This got removed by #110393.

@RalfJung RalfJung closed this as completed Sep 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-const_trait_impl `#![feature(const_trait_impl)]` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants