Anti-Pattern: Intermediate collect()ion

[llogiq]

I sometimes see this in code from iterative-minded folks, they iterate over something, collecting the result in a Vec. Then they iterate over the Vec, producing yet another Vec.

In most cases, the intermediate storage can be avoided. However, there are two exceptions:

• When start()ing a number of threads one intends to join() later, the intermediate storage is needed to allow the threads to run concurrently.
• Sometimes the intermediate storage can help the LLVM optimizer autovectorize some calculations that it would bail on were the iterations fused. In such cases, specific measurements should guide the implementation.

[oli-obk]

• when you are collecting an Iterator<Item = Result<T, U>> into a Result<Vec<T>, U>, but the error production has a side-effect that you need. This actually occurs in rustc, where you don't want to stop reporting errors after the first error.

[briansmith]

Collecting early and then iterating over the vector allows one to avoid parameterizing the code that does the iterating over the iterator type, right? I would say that the most common anti-pattern I see in Rust is unnecessarily parameterized functions; e.g. fn foo<W: Write>(w: &mut W) instead of fn foo(w: &mut Write).

[llogiq]

The latter uses a fat pointer+vtable whereas the former does static dispatch, am I right? In that case, it depends on whether you agree to the runtime cost of dynamic dispatch (which is often negligible) or not (e.g. in a tight loop).

[briansmith]

The latter uses a fat pointer+vtable whereas the former does static dispatch, am I right? In that case, it depends on whether you agree to the runtime cost of dynamic dispatch (which is often negligible) or not (e.g. in a tight loop).

I usually see people doing it the parameterized way when performance isn't an issue and/or when it isn't clear that dynamic dispatch is worse than the effects of code bloat that results from parameterization.

[nrc]

There are other downsides for using trait objects rather than generics - in particular you have to care about object safety which is a fiddly topic.

The preferred solution is impl Trait, but that is unstable and incomplete.

[softprops]

The preferred solution is impl Trait, but that is unstable and incomplete.

For this, I can not wait :)

[briansmith]

My point is that Intermediate collect()ion is often good if one's goal is to avoid reduce type-parameterized code. I'm not debating whether or not that is a good goal.