Simplify Option::into_flat_iter signature

[WaffleLapkin]

impl<T: IntoIterator> Option<T> {
-    pub fn into_flat_iter<A>(self) -> OptionFlatten<A>
-    where
-        T: IntoIterator<IntoIter = A>,
+    pub fn into_flat_iter(self) -> OptionFlatten<T::IntoIter> {
}

This is marked as an unresolved question (#148441, #148487 (comment)), but I cannot come up with any reason to have this generic.

[rustbot]

r? @Darksonn

rustbot has assigned @Darksonn.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from 6 candidates

[hanna-kruppe]

I can't come up with a good reason either. cc @scottmcm since you originally raised the question.

There is one minor, mechanical difference: with the old signature, you can turbofish the iterator type. But if type annotations are needed, then it's virtually always easier to name iterable types than to name iterator types (which are rarely imported and named, and sometimes can't be named at all). And it seems unlikely to have a situation where type inference got far enough to resolve the method call, but still needs hints about some aspects of the IntoIterator type. Github code search doesn't seem to know of any calls that use turbofish, either.

[Darksonn]

This also looks reasonable to me.

[hanna-kruppe]

I'm just gonna go ahead and approve this. If there's some reason not to do this that everyone has missed so far, libs-api can still consider it as part of stabilization. But I don't feel that's very likely, so no need to preemptively involve any heavier process IMO.

r? hanna-kruppe @bors r+ rollup

[rust-bors]

📌 Commit cc71d5c has been approved by hanna-kruppe

It is now in the queue for this repository.

[scottmcm]

There is one minor, mechanical difference: with the old signature, you can turbofish the iterator type. But if type annotations are needed, then it's virtually always easier to name iterable types than to name iterator types

Agreed. There might be a reason this would be handy if it was allowing something like into_flat_iter::<u8>() to control a literal or something, but I can't imagine people really wanting to turbofish the iterator type.