I have created a marginally useful crate, `const-size-flatten` (and have some thoughts about `core` and specialization)

My crate (docs, source) provides versions of Flatten and FlatMap that take advantage of their intermediate yielded items implementing the also provided ConstSizeIntoIterator to accurately gauge their remaining size. In a previous version ConstSizeFlatten and ConstSizeFlatMap implemented ExactSizeIterator, but I was made aware of the fact that even if the component iterators implement ExactSizeIterator correctly, the resulting length could be above usize::MAX meaning that len() could panic.

I believe this functionality should be in core’s Flatten and FlatMap, because it actually already is—for arrays. The problem is that core implements this rather obtusely and non-extensibly via a private trait and specialization. It seems to me that once specialization is stabilized a new feature could be built on top of it, trait-conditional control flow, wherein a function can be functionally different for types that implement a trait and ones that don’t. This would allow a much more sensible implementation than core currently uses that could be made public while providing the improved accuracy my crate provides.

What core does is instead of having a trait ConstSizeIntoIterator: IntoIterator { const SIZE: usize; }, it has a trait ConstSizeIntoIterator: IntoIterator { const SIZE: Option<usize>; } with a blanket impl for all compatible types, and specializes this implementation for {,&{,mut} }[T; N]. I believe that at least some traits could automatically be converted into this form in the background allowing for an easy minimal implementation of trait-conditional control flow.

My crate’s ConstSizeIntoIterator currently requires implementor’s IntoIter implements ExactSizeIterator, but I am looking into relaxing this restriction.

Some previous libs-api feedback: Produce better size_hints from Flatten & FlatMap by scottmcm · Pull Request #48544 · rust-lang/rust · GitHub

That's 5 years ago now, though, so maybe appetites have changes, or maybe there's a better approach.

Alternatively, it might be interesting to have a "size-aware transform" system of some sort, since arrays would also like such a thing so that an infallible array → array function can exist.

Hm, interesting. That’s of course one other way to do that.
My suggestion seems more tenable to me because core already has this feature, it’s just not extensible.

OK, as it turned out my implementation was subtly wrong. Fix out now, old version yanked.