Skip to content

Option::zip #1475

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

Closed
retep998 opened this issue Jan 23, 2016 · 9 comments
Closed

Option::zip #1475

retep998 opened this issue Jan 23, 2016 · 9 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@retep998
Copy link
Member

I sure would like to have the method Option::zip

fn zip<U>(self, Option<U>) -> Option<(T, U)>

Currently I have to do a.into_iter().zip(b).next() which is just a tiny bit verbose.

@huonw
Copy link
Member

huonw commented Jan 24, 2016

a.and_then(|x| b.map(|y| (x, y))) also works, although isn't much less verbose.

@rphmeier
Copy link

The desired behavior here is to return Some iff self and other are Some?
The signature looks like it should take self by value rather than by ref.

I think this is a pretty good idea since it's so simple, but I am not sure what the use-case is.

@oli-obk
Copy link
Contributor

oli-obk commented Jan 26, 2016

alternatively there could be an impl<T, U> Into<Option<(T, U)>> for (Option<T>, Option<U>). But that might be a bit too much logic for the into operation.

@KalitaAlexey
Copy link

Option::zip(a, b)

vs

(a, b).into()

I think that second approach is better, but it type of (a, b).into() is not inferrable right now.

@frewsxcv
Copy link
Member

👎 for me. It seems like a niche use case. Also, having an operation named zip on Iterator that acts slightly different seems unfortunate.

@glaebhoerl
Copy link
Contributor

FWIW using #243 extended with Option compatibility, it would also be possible to express this as try { (a?, b?) }.

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 18, 2016
@retep998
Copy link
Member Author

This is now implemented, although unstable.

Closing in favor of tracking issue: rust-lang/rust#70086

@hadronized
Copy link
Contributor

hadronized commented Jun 11, 2020

Interesting idea. That’s basically a specialization of applicative functors. Indeed, you use a tuple constructor, but you could do much more with an applicative functor. It’s a pity we don’t have applicative functor notation in Rust. :)

As a base of comparison, you do it this way in Haskell:

-- all these are identical
x = liftA2 (,) firstMaybe secondMaybe

x = (,) <$> firstMaybe <*> secondMaybe

x = do
  a <- firstMaybe
  b <- secondMaybe
  pure (a, b)

@WaffleLapkin
Copy link
Member

@phaazon note that we have special-cased do (I think?...) for some types, e.g.:

let x = try { (first?, second?) };

The try{} block itself is unstable (rust-lang/rust#31436) but the question mark operator in functions is stable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

10 participants