Just a quick riff/hack on whether it'd be hard to make a `collect()` method that "collected" into a `Vec` without needing any turbofish (see, if you're interested, my [prior post on the `turbofish`](https://lemmy.ml/post/17715376). *Some grasp of traits and iteration is required to comfortably get this ... though it might be a fun dive even if you're not* ### Background on `collect` The implementation of `collect` is: ```rust fn collect>(self) -> B where Self: Sized, { FromIterator::from_iter(self) } ``` The generic type `B` is bound by `FromIterator` which basically enables a type to be constructed from an `Iterator`. In other words, `collect()` returns *any* type that can be built from an interator. EG, `Vec`. The reason the `turbofish` comes about is that, as I said above, it returns "*any* type" that can be built from an iterator. So when we run something like: ```rust let z = [1i32, 2, 3].into_iter().collect(); ``` ... we have a problem ... rust, or the `collect()` method has no idea what type we're building/constructing. More specifically, looking at the code for `collect`, in the call of `FromIterator::form_iter(self)`, which is calling the method on the trait directly, rust has no way to determine *which implementation* of the trait to use. The one on `Vec` or `HashMap` or `String` etc?? Thus, the `turbofish` syntax specifies the generic type `B` which (somehow through type inference???) then determines which implementation to use. ```rust let z = [1i32, 2, 3].into_iter().collect::>(); ``` *IE: Use the implementation on `Vec`!* ### Why not just use `Vec`? I figure `Vec` is used so often as the type for collecting an `Iterator` that it could be nice to have a convenient method. The docs even hint at this by suggesting that calling the `FromIterator::from_iter()` method directly from the desired type (eg `Vec`) can be more readable (see [`FromIterator` docs](https://doc.rust-lang.org/core/iter/trait.FromIterator.html)). *EG ... using `collect`*: ```rust let d = [1i32, 2, 3]; let x = d.iter().map(|x| x + 100).collect::>(); ``` *Using `Vec::from_iter()`* ```rust let y = Vec::from_iter(d.iter().map(|x| x + 100)); ``` As `Vec` is always in the prelude (IE, it's always available), using `from_iter` clearly seems like a nicer option here. *But you lose method chaining!* So ... how about a method on `Iterator`, like `collect` but for `Vec` specifically? How would you make that and is it hard?? ### Making `collect_vec()` *It's not hard actually* * Define a trait, `CollectVec` that defines a method `collect_vec` which returns `Vec` * Make this a "sub-trait" of `Iterator` (or, make `Iterator` the "supertrait") so that the `Iterator::collect()` method is always available * Implement `CollectVec` for all types that implement `Iterator` by just calling `self.collect()` ... *the type inference will take care of the rest, because it's clear that a `Vec` will be used*. ```rust trait CollectVec: Iterator { fn collect_vec(self) -> Vec; } impl CollectVec for I { fn collect_vec(self) -> Vec { self.collect() } } ``` With this you can then do the following: ```rust let d = [1i32, 2, 3]; let d2 = d.iter().map(|x| x + 1).collect_vec(); ``` Don't know about you, but implementing such methods for the common collection types would suit me just fine ... that turbofish is a pain to write ... and AFAICT this isn't inconsistent with rust's style/design. And it's super easy to implement ... the type system handles this issue very well.

maegul (he/they)

Moderates