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 Option::xor #50512

Open
Milack27 opened this Issue May 7, 2018 · 9 comments

Comments

Projects
None yet
7 participants
@Milack27

Milack27 commented May 7, 2018

Today I got myself in a situation in which I had two Option<T> values, and I wanted to return the only one that was Some. If both of them were Some, then I'd rather return None. I think it would be perfect to have a xor method, very similar to the or method:

impl<T> Option<T> {

    //...

    fn xor(self, optb: Option<T>) -> Option<T> {
        match (&self, &optb) {
            (&Some(_), &None) => self,
            (&None, &Some(_)) => optb,
            _ => None,
        }
    }
}

I think that would solve my problem nicely, and could be useful for a lot of people as well.

@Milack27 Milack27 changed the title from Add `xor` method to `Option<T>` to Add xor method to Option<T> May 7, 2018

@clarcharr

This comment has been minimized.

Contributor

clarcharr commented May 7, 2018

There should also be an xor_else method, similar to or_else.

@ollie27

This comment has been minimized.

Contributor

ollie27 commented May 7, 2018

There would be no point in a xor_else because you always have to evaluate the second argument.

@clarcharr

This comment has been minimized.

Contributor

clarcharr commented May 8, 2018

…good point. Never mind, then.

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue May 17, 2018

Rollup merge of rust-lang#50553 - clarcharr:option_xor, r=sfackler
Add Option::xor method

Implements the method requested in rust-lang#50512.
@Milack27

This comment has been minimized.

Milack27 commented May 18, 2018

Implemented on #50553.

@Milack27 Milack27 closed this May 18, 2018

@clarcharr

This comment has been minimized.

Contributor

clarcharr commented May 18, 2018

@Milack27 You actually need to keep this issue open as a tracking issue. It hasn't been stabilised yet, so, it can only be used with #![feature(option_xor)] at the moment.

If you could rename this issue to "Tracking issue for Option::xor" it would also help make that clear.

@kennytm kennytm reopened this May 18, 2018

@Milack27 Milack27 changed the title from Add xor method to Option<T> to Tracking issue for Option::xor May 18, 2018

@sfackler sfackler added the B-unstable label May 18, 2018

@Milack27

This comment has been minimized.

Milack27 commented May 18, 2018

@clarcharr Oops, sorry! Just fixed it.

@pravic

This comment has been minimized.

Contributor

pravic commented May 23, 2018

Aren't new methods supposed to be added via RFC?

@Milack27

This comment has been minimized.

Milack27 commented May 23, 2018

@pravic I don't know. The same concern was raised in #50553, but it seems the approval of the libs team is sufficient. Initially, I just posted this issue as a feature suggestion, expecting to get the opinions of the community members before going through the RFC process. Nevertheless, I can still write an RFC if it's needed.

@clarcharr

This comment has been minimized.

Contributor

clarcharr commented May 23, 2018

@pravic depends on what kind of method. Simple ones like this are implemented and left unstable to be used by the community, and usually that + a final comment period is enough to accept a feature. Ones that are more iffy on the design need RFCs though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment