Include `collect_vec` in `std`?

[burntsushi]

I like this too. It’s a very common thing that I type, especially in tests.

[leonardo]

but we’d want/need to do it in a way that doesn’t blow up itertools users.

This is a general problem with itertools, because it contains some other things we’ll want in std. How to face this problem better?

[drXor]

This is a general problem with itertools, because it contains some other things we’ll want in std. How to face this problem better?

++

I think going through crates.io and looking at what the most popular itertools calls are might be a good idea.

[Centril]

How to face this problem better?

Generally speaking; I think the solution going forward is to make PRs for the standard library first and only to itertools if it can’t be in the standard library or T-libs doesn’t want it.

I recently got a PR to itertools regarding this merged: https://github.com/bluss/rust-itertools/pull/294

[matklad]

Yes please!

Do name it to_vec though: itertools useses wordy collect specifically to avoid conflict with more appropriate to_vec.

My rational for this:

• it helps with type inference: compiler gives better error messages, IDE can give sane completions even if the following code is not written yet, human can read function top-down to infer the types.

• it helps with more fluent coding: collect + turbofish is a lot of symbols!

• it uses less power, which is good. Return type polymorphism is one of the greatest features of rust, but if you don’t use it in generic context, then it is just an unnecessary complication.

[josh]

This would consume the iterator, so shouldn’t it be into_vec?

[Centril]

This would consume the iterator, so shouldn’t it be into_vec ?

I like this better but it should be into_vec to follow the naming conventions

Yes, it should be called into_vec.

[kornel]

Alternatively (and I think it’s been mentioned before), could .collect() have a default type it collects to?

[djc]

+1 in the name of paving the cow paths.

[sfackler]

Method type parameters can’t have defaults.

[kornel]

Could they be made to have defaults?

[cuviper]

Even if it could, Iterator is in core where the Vec type doesn’t exist yet.

Actually, this seems to be a problem for the entire thread here, no?

[sfackler]

Yeah, it’d have to be a separate trait with a blanket impl in std.

[Centril]

Method type parameters can’t have defaults.

Could they be made to have defaults?

There was an RFC: https://github.com/rust-lang/rfcs/pull/2321

[spease]

I’ve done this a lot too, but often with the Vec wrapped in Result. I often want to run things through iterators as the ability to chain gives me great flexibility, but have to bleed off the errors somehow.

[JoeyAcc]

Personally I find I never need to use turbofish for collecting data. I use collect() when either I need to return a regular collection (e.g. a Vec) rather than an Iterator, and otherwise only when I need to get a regular collection as a local (this one is increasingly rare).

In the first use case, I just to .collect() and let type inference take care of the rest. The latter mostly used to happen before impl Trait became stable, and then only when I couldn’t chain methods on the Iterator any further e.g. because I needed to pass an owned collection of the iterated items.

So mostly I’m just wondering: What makes you use the turbofish when using .collect()?

[sfackler]

A common example:

fn foo(s: &[u8]) { ... }

fn main() {
    let v = (0..128).collect();
    foo(&v);
}

error[E0277]: the trait bound `[u8]: std::marker::Sized` is not satisfied
 --> src/main.rs:4:9
  |
4 |     let v = (0..128).collect();
  |         ^ `[u8]` does not have a constant size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for `[u8]`
  = note: all local variables must have a statically known size

error[E0277]: the trait bound `[u8]: std::iter::FromIterator<{integer}>` is not satisfied
 --> src/main.rs:4:22
  |
4 |     let v = (0..128).collect();
  |                      ^^^^^^^ a collection of type `[u8]` cannot be built from an iterator over elements of type `{integer}`
  |
  = help: the trait `std::iter::FromIterator<{integer}>` is not implemented for `[u8]`

[dhardy]

I’ve been using the Turbofish quite a few times recently. One example is testing functions which return an iterator, where for testing the complete output it’s easiest to compare against a Vec (seems like type inference should work here, but it wasn’t); also in case the iterator output must be used multiple times and the iterator cannot be cloned then the output must be collected.

---

It seems like there’s quite a bit of support for adding Iterator::into_vec, but as pointed out this isn’t possible.

An alternative is to add a trait like trait IntoVec { type T; fn into_vec(self) -> Vec<T>; }, but adding a trait just for this seems unreasonable.

Another possibility: Vec::collect_from(iter).

Or maybe we just have to accept that adding this isn’t reasonable?

[Nemo157]

Another possibility: Vec::collect_from(iter) .

Do you mean

use std::iter::FromIterator;
Vec::from_iter(iter);

I’m still not sure if Editions can add new traits to the prelude, maybe FromIterator could be included in Edition 2018? Checking github it was briefly mentioned in https://github.com/rust-lang/rust/pull/51434

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.