Tracking Issue for `Option::into_flat_iter`

[Qelxiros]

Feature gate: #![feature(option_flat_iter)]

This is a tracking issue for Option::(into_)flat_iter, methods for getting iterators out of Options.

Public API

impl<T> Option<T> where T: IntoIterator {
    pub fn into_flat_iter(self) -> OptionFlatten<<T as IntoIterator>::IntoIter>;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: Option::map_iter() to create an iterator from Option libs-team#626
• Implementation: add Option::into_flat_iter #148487
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Should there be into_flat_iter and flat_iter or just into_flat_iter and as_ref/as_mut?

• This is currently done as pub fn into_flat_iter<A>(self) -> OptionFlatten<A> where T: IntoIterator<IntoIter = A>, but do we want the A there or should it be pub fn into_flat_iter(self) -> OptionFlatten<<T as IntoIterator>::IntoIter>? see Simplify Option::into_flat_iter signature #158741

• Should this be unconditionally fused (since the iterator is holding an Option anyway), or only fused when the inner iterator is fused?

• Should Result have this too, since it's also IntoIterator?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Qelxiros]

@ChayimFriedman2 Do you still want to implement this? If not, I'm happy to try. Regardless, rust-lang/libs-team#626 should be closed.

[zachs18]

(for the "Unresolved Questions" section):

Should the by-ref version be spelled as opt.as_ref().into_flat_iter() instead of having a dedicated method?

Alternately, should there be a by-mut-ref method (e.g. flat_iter_mut), instead of spelling it as opt.as_mut().into_flat_iter()?

[ChayimFriedman2]

@Qelxiros Feel free to take this, but I was waiting an answer to rust-lang/libs-team#626 (comment).