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.