Remove Option's IntoIterator?

language design
1

Option and Result implement IntoIterator.

for surprise in Some(vec![1,2,3]) {
}

Is there a strong use-case for it? All I can think of is already handled better by if let or dedicated Option/Result methods.

I’ve only used it by accident when I forgot to unwrap a value and instead of getting type error in the right place, I ended up with a “loop” that doesn’t make sense.

If it’s not used in the wild, can it be deprecated and eventually removed?

1 Like
2

I know at least one usage in the wild: https://github.com/rust-lang/cargo/blob/9d57564a62360a9b637d3c45d919b7d08d59fead/src/cargo/core/compiler/context/unit_dependencies.rs#L189. This is .chain(::std::iter::once), without importing iter. A hack most definitely!

3

It was added after enough people asked for it to be used. I don’t see why we should remove it; it’s a pretty classic operation.

3 Likes
4

I do use it, for example if I want to optionally append something to another iterator and I already have it as an Option. It could be worked around without it, but I find it handy ‒ after all, Option is a container with 0 or 1 element.

3 Likes
5

I find (at least having it available as a method) very useful with (the unstable) Iterator::flatten:

fn foo() -> Option<Vec<u32>> { ... }
fn bar() -> impl Iterator<Item = u32> {
    foo().into_iter().flatten()
}

Although, that would be fine with just having it as an inherent method. It could be useful in the opposite direction as well to turn an iterator of optional values into an iterator over just the existing values, which would require the IntoIterator implementation.

6

OK, I see removal is not an option. Thanks!

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.