Tracking Issue for `Option::zip` and `Option::zip_with` (feature `option_zip`)

[LukasKalbertodt]

This is a tracking issue for #![feature(option_zip)] which was introduced in #69997.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Stabilize Option::zip (Stabilize Option::zip #72938)
• Resolve unresolved questions
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Should we also include zip_with in the public API? Seems like a niche API and is easily replaced with a.zip(b).map(f).

[cwfitzgerald]

For what it's worth: my personal two cents are that both should be included, as even if zip_with's use may be a bit more rare, I think the pattern of (Option, Option) -> Option<Something> is common enough, and the terseness win is great enough, that it should be kept.

Edit: One note is that zip_with and zip().map() take different functions as argument, the former takes FnOnce(T, U) -> R the other takes FnOnce((T, U)) -> R, the former of which is generally more directly useful to calling off to other methods.

Edit 2: Is there a better place for this discussion, or is here okay?

[WaffleLapkin]

Edit: One note is that zip_with and zip().map() take different functions as argument, the former takes FnOnce(T, U) -> R the other takes FnOnce((T, U)) -> R, the former of which is generally more directly useful to calling off to other methods.

Yeah, I've just found the same thing. E.g.:

let a: Option<i32> = ...;
let b: Option<i32> = ...;
let res = a.zip_with(b, Add::add);
// or
let res = a.zip(b).map(|(a, b)| a + b); // destruction needed 

I think in this example zip_with is nicer/clearer than zip+map

[tesuji]

I opened a PR to stabilize Option::zip only: #72938

[qm3ster]

I was originally looking for this, but I feel like the upcoming try_blocks greatly diminished the uses.

let a = Some(7);
let b = Some(true);
let out = a.iter().zip(b).map(|(a, b)| s * o as u8).next(); //stable
let out = a.zip(b).map(|(a, b)| a * b as u8); // #![feature(option_zip)]
let out = a.zip_with(b, |a, b| a * b as u8); // #![feature(option_zip)]
let out: Option<_> = try { a? * b? as u8 }; // #![feature(try_blocks)]

wow, such expressivity!
@WaffleLapkin's case:

let res = a.zip_with(b, Add::add);
let res = try { a? + b? };

Option::zip is still king for the trivial zipping action in isolation:

wants_tuple(a.iter().zip(b).next()); //stable
wants_tuple(a.zip(b)); // #![feature(option_zip)]
wants_tuple(try { (a? * b?) }); // #![feature(try_blocks)]

[WaffleLapkin]

One interesting note is that try { (a?, b?) } is lazy, where is a.zip(b) is not. However, I personally think that the later is easier to read (I think that early returns are weird in cases like that or Ok(res?)).

Maybe we should also implement smt like this:

fn zip_lazy(self, f: impl FnOnce() -> Option<U>) -> Option<T, U> { ... }

? 🤔