Giacomo Stevanato

@topni1 I'm kinda in your same situation, the old one didn't work, I changed the packages and now it kinda works, though I don't think my images are that good...

Yes, it would be possible. What you're proposing is essentially merging the `GroupingByExt::grouping_by` and `Grouping::aggregate`/`fold`/`fold_first` methods of my example, which is 100% possible from a technical point of view. This...

> I would expect that .cloned().cloned() is just as efficient -- maybe even more efficient since it's using core methods which could have some fancy internal optimizations. I wouldn't be...

That's why I said "when collecting in place is possible". For that to be possible you need to have the original `Vec`'s items type and the collecting items type to...

How about something like: ```rust trait JoinableIterator: Iterator { fn join(self, sep: S) -> O where Self: Sized, O: Join { O::join(self, sep) } } impl JoinableIterator for I {}...

I based myself on the current implementation which requires `Self::Item: Display`, so I kept that bound. I think the original idea was that a join with `String`s/`&str`s only would require...

> User could still use &str if they want it to be more efficient so they don't want to allocate, we probably also does not want to force String, maybe...

> Say, if users have Vec do we want them to implement Display or would we want them to convert it themselves to String? If we allow Display they may...

And what about something that acts like `iterator.map(function).flatten_ok()`?

The `Iterator` trait requires the elements to be able to outlive the iterator itself, so you can't just store the result of the closure passed to `with_ref_to` in the iterator...