Anti-Pattern: Intermediate `collect()`ion about patterns HOT 7 OPEN

• 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.

from patterns.

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).

from patterns.

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).

from patterns.

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.

from patterns.

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.

from patterns.

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

For this, I can not wait :)

from patterns.

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.

from patterns.