Tracking Issue for Option::unzip()

[Kixiron]

Feature gate: #![feature(unzip_option)]

This is a tracking issue for the Option::unzip() method, which turns an Option<(T, U)> into an (Option<T>, Option<U>).
This is the inverse of Option::zip() and is a nice little convenience function

Public API

// core::option

impl<T, U> Option<(T, U)> {
    pub fn unzip(self) -> (Option<T>, Option<U>);
}

Steps / History

• Implementation: Added the Option::unzip() method #87636
• Final comment period (FCP)
• Stabilization PR: Stabilize Option::unzip() #98204

Unresolved Questions

• None yet.

[camsteffen]

What is a use case for this?

I don't think this can be justified merely by the existence of Option::zip. It seems much less useful. I think Option::zip is useful because it functions as a logical AND.

[Kixiron]

The use case is for turning an option of tuples into a tuple of options, I've ran into needing it a few times

[camsteffen]

Simply stating what the function does is not a use case. What is the code, what does it do, and importantly what does the alternative look like?

[Kixiron]

My code looked generally like this

let (x, y) = if let Some((x, y)) = foo() {
    (Some(x), Some(y))
} else {
    (None, None)
};

// Use x and y separately

With unzip that'd be this

let (x, y) = foo().unzip();

The only alternatives to unzip are relatively verbose match or if let statements

[camsteffen]

Can you give more context? A use case would show how the function might be used in a real life scenario. It should also demonstrate that the usage cannot be easily refactored to something else. There is no way to know how // Use x and y separately could be refactored without seeing actual code.

[Kixiron]

x and y are each used separately, they're passed as individual arguments or something. Otherwise you'd have to either rebind each of them with thing.map(|(x, )| x) or inline that map at each use site

[Kixiron]

Some code I was trying to write today:

// Without `.unzip()`
impl<'a, T> Iterator for EdgeIter<'a, T> {
    type Item = &'a Edge<T>;

    fn next(&mut self) -> Option<Self::Item> {
        let edges = self.edges.and_then(|edges| {
            if let [edge, rest @ ..] = edges {
                Some((rest, edge))
            } else {
                None
            }
        });
        self.edges = edges.map(|edges| edges.0);

        edges.map(|edges| edges.1).and_then(|next_id| {
            let next = self.edge_data.get(next_id);
            debug_assert!(next.is_some(), "edge data missing edge {}", next_id);

            next
        })
    }
}

// With `.unzip()`
impl<'a, T> Iterator for EdgeIter<'a, T> {
    type Item = &'a Edge<T>;

    fn next(&mut self) -> Option<Self::Item> {
        let (edges, next) = self
            .edges
            .and_then(|edges| {
                if let [edge, rest @ ..] = edges {
                    Some((rest, edge))
                } else {
                    None
                }
            })
            .unzip();
        self.edges = edges;

        next.and_then(|next_id| {
            let next = self.edge_data.get(next_id);
            debug_assert!(next.is_some(), "edge data missing edge {}", next_id);

            next
        })
    }
}

[camsteffen]

How about this?

fn next(&mut self) -> Option<Self::Item> {
    if let Some(edges) = self.edges {
        if let [next_id, rest @ ..] = edges {
            self.edges = Some(rest);
            let next = self.edge_data.get(next_id);
            debug_assert!(next.is_some(), "edge data missing edge {}", next_id);
            return next;
        }
    }
    None
}

[Kixiron]

Doesn't really work, there's a significantly larger amount of work going on that I removed

[camsteffen]

Okay, then you still haven't demonstrated the usefulness of Option::unzip.

[repnop]

I don't think its particularly productive to argue over some arbitrary metric of "usefulness" that's entirely subjective since this it may come up more often in some domains compared to others -- if you have concerns with the method w.r.t its interactions with other parts of the language or the implementation, it's much more productive to discuss those. Plus, having the inverse operation for one that already exists seems perfectly reasonable, at least to me.

Okay, then you still haven't demonstrated the usefulness of Option::unzip.

This comes off quite rude, Kixiron already posted snippets of code with which he found it handy to have, and is not required to copy and paste entire files of code to "prove" its usefulness to you.

[camsteffen]

I'm sorry for coming off rude.

[mehcode]

To add a concrete data point, I often run into needing this when dealing with databases. I'll have a nice rusty optional tuple of data that I need to transpose into a tuple of options to then pass into a query.

I'd love to see this for N variants. The itertools crate has a izip! for an N-variant Option::zip that is quite useful. But having a simple two-variant in the std is a useful building block.

[jimblandy]

I was surprised to find myself wanting this today:

pub fn map_interpolation(
    interp: (&str, Span),
    sampling: Option<(crate::Sampling, Span)>,
) -> Result<crate::Interpolation, Error<'_>> {
    // Option::unzip is not stable.
    let (sampling, sampling_span) = match sampling {
        Some((sampling, span)) => (Some(sampling), Some(span)),
        None => (None, None),
    };
    match interp.0 {
        "linear" => Ok(crate::Interpolation::Linear(
            sampling.unwrap_or(crate::Sampling::Center),
        )),
        "flat" => {
            if let Some(span) = sampling_span {
                return Err(Error::SamplingNotPermitted {
                    interpolation: interp.1,
                    sampling: span,
                });
            }
            Ok(crate::Interpolation::Flat)
        }
        "perspective" => Ok(crate::Interpolation::Perspective(
            sampling.unwrap_or(crate::Sampling::Center),
        )),
        _ => Err(Error::UnknownInterpolation(interp.1)),
    }
}

The two components of sampling are needed on different paths, and the unzip seems nicer than scattering little .map(|_, span| span) adapters everywhere.

[lilyball]

I just ran into this today. I have code like

let foo = self.bar.map(|bar| {
    let (value, guard) = process(bar);
    Some(value, guard)
});

and what I really want to say is

let (foo, _guard) = self.bar.map(|bar| {
    let (value, guard) = process(bar);
    Some(value, guard)
}).unzip();

Having to split this apart myself is annoying. Doing this as a map makes perfect sense, instead I'm going to have to use an if let Some(bar) = self.bar { … } else { (None, None) }.

[wbenny]

Same,

I have roughly following code:

pub struct Metadata {
    pub file_type: Option<String>,
    pub file_mime: Option<String>,
    ...
}

fn get_type_and_mime(path: &str) -> Option<(String, String)>;

fn from_path(path: &str) -> Metadata {
    let (file_type, file_mime) = get_type_and_mime(path).map_or( // < this could be replaced by unzip() but you playin
                (None, None),
                |(t0, t1)| (Some(t0), Some(t1))
            );
    // ...
    Metadata {
        file_type,
        file_mime,
        ...
    }
}

[coolreader18]

Would've found this useful in conjunction with split_once today:

let (host, port) = addr_str.split_once(':').unzip();
let host = host.unwrap_or(&addr_str);
let port = port.map(|p| p.parse::<u16>()).transpose()?;

[Stargateur]

I'm unsure I will ever need this cause I also never used zip, but feel very reasonable to me since there have been no remark on the implementation since +6 months I think you can do a PR for a stabilisation @Kixiron

[Kixiron]

@rust-lang/libs-api can we start the FCP for this?

[cyqsimon]

I would like to add that this is very often useful when dealing with functions that return a value pair, which is fairly common.

E.g. mpsc::channel, UnixStream::pair

[karx1]

I needed this today, I have:

        let orig = manager
            .get_focused()
            .await
            .map(|w| (w, manager.get_framed_window(w)));

However, I need to use the focused and the framed window separately, which is where unzip would have come in handy.

[Amanieu]

Proposing stabilization of Option::unzip():

// core::option

impl<T, U> Option<(T, U)> {
    pub fn unzip(self) -> (Option<T>, Option<U>);
}

@rfcbot merge

[rfcbot]

Team member @Amanieu 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
• @yaahc

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.

[danjl1100]

I stumbled upon a use case similar to the posts above, and I think this would be useful. 👍

To clarify (and possibly strengthen the argument for stabilizing)...
Is the general consensus that is only for 2-tuples Option<(T, U)> (and not that "larger N-tuples" Option<(T, U, V, ...)>) because the current Option::zip() method only operates on 2-tuples?

This seems like a natural rationale for why this PR may be accepted, while future a N-tuple unzip may not.

[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.