Change:
Feature gate: This is a tracking issue for the method, which turns an into an . This is the inverse of and is a nice little convenience function [x] Implementation: [x] Final comment period (FCP) [x] Stabilization PR: None yet.
What is a use case for this? I don't think this can be justified merely by the existence of . It seems much less useful. I think is useful because it functions as a logical AND.
The use case is for turning an option of tuples into a tuple of options, I've ran into needing it a few times
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?
My code looked generally like this With unzip that'd be this The only alternatives to unzip are relatively verbose or statements
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 could be refactored without seeing actual code.
and are each used separately, they're passed as individual arguments or something. Otherwise you'd have to either rebind each of them with or inline that map at each use site
Some code I was trying to write today:
How about this?
Doesn't really work, there's a significantly larger amount of work going on that I removed
Okay, then you still haven't demonstrated the usefulness of .
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. 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.
I'm sorry for coming off rude.
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 for an N-variant that is quite useful. But having a simple two-variant in the std is a useful building block.
I was surprised to find myself wanting this today: The two components of are needed on different paths, and the seems nicer than scattering little adapters everywhere.
(nevermind, it doesn't actually work in my case due to how works)
I just ran into this today. I have code like and what I really want to say is Having to split this apart myself is annoying. Doing this as a makes perfect sense, instead I'm going to have to use an .
Same, I have roughly following code:
Would've found this useful in conjunction with today:
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
can we start the FCP for this?
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. ,
I needed this today, I have: However, I need to use the focused and the framed window separately, which is where would have come in handy.
Proposing stabilization of : merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] [x] 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 for info about what commands tagged team members can give me.
I stumbled upon a use case similar to the posts above, and I think this would be useful. :+1: To clarify (and possibly strengthen the argument for stabilizing)... Is the general consensus that is only for 2-tuples (and not that "larger N-tuples" ) because the current method only operates on 2-tuples? This seems like a natural rationale for why this PR may be accepted, while future a N-tuple may not.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , 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.

Discussion:
/// # Examples /// /// ``` <del> /// #![feature(unzip_option)] /// </del> /// let x = Some((1, "hi")); /// let y = None::<(u8, u32)>; ///

/// assert_eq!(y.unzip(), (None, None)); /// ``` #[inline] <del> #[unstable(feature = "unzip_option", issue = "87800", reason = "recently added")] pub const fn unzip(self) -> (Option<T>, Option<U>) { </del> <ins> #[stable(feature = "unzip_option", since = "CURRENT_RUSTC_VERSION")] #[rustc_const_unstable(feature = "const_option", issue = "67441")] pub const fn unzip(self) -> (Option<T>, Option<U>) where T: ~const Destruct, U: ~const Destruct, { </ins> match self { Some((a, b)) => (Some(a), Some(b)), None => (None, None),

#![feature(strict_provenance)] #![feature(trusted_random_access)] #![feature(unsize)] <del> #![feature(unzip_option)] </del> #![feature(const_array_from_ref)] #![feature(const_slice_from_ref)] #![feature(waker_getters)]