re-export Vec in the collections crate

[thestinger]

Closes #12542

[alexcrichton]

This would introduce two ways to do the same thing, which we've generally shied away from doing. The current decision is to use std::vec::Vec instead of collections::Vec. I would rather revisit that before providing two methods to import a vector.

[thestinger]

I don't see why the collections module would exclude collections we use in the standard library. It's a module for a collection, and whether it is a crate is not relevant from an API perspective. If anything, it should be deprecated to use it directly from std::vec_ng outside of the standard library. It's an inconsistent API design.

Not re-exporting collections defined in the standard library means if one of the other collections like a hash table, it requires a backwards incompatible change. There are many use cases for a map or set in the standard library. At the moment, it makes use of various sets and maps used by the standard C library (like the allocator) but these may be in Rust in the future.

[thestinger]

I think the endless questions like this indicate poor API design:

jaredly\ | I'm trying to use Arcs, but it looks like UnsafeArc is the only one in std::sync. Am I looking in the wrong place?

The UnsafeArc type should be available in libsync and not elsewhere. This allows users of the language to look in that crate for shared memory features, and avoids a messy API spread across many crates. It don't see the logic in doing anything else. If incremental compilation means the API to be spread all over the place, it's going to get harder and harder to predict where stuff will be as it's split up more and it means that any time the compilation model is altered a bit, backwards compatibility will have been broken.

[brson]

Thanks for the pull request.

Pull requests should have supporting that the feature is desired, but this pull request links to an issue that was already closed as wontfix. If you want to change people's opinions I recommend doing it in a more diplomatic way.

Closing.

[thestinger]

The issue wasn't closed as WONTFIX. The reply only rejects moving Vec<T> to another crate, and I never planned to do that.

[emberian]

I support this change.

[huonw]

I'm in favour of it too, although rustdoc will need to be changed to be able to inline docs of cross-crate reexports at some point too.

[brson]

@huonw @cmr Nobody will ever use a Vec exported from this crate. Why do you want it?

[huonw]

I was under the impression that later changes (i.e. moving it to a "secret" module in std) would make this the canonical location for Vec, so the conventional way to import it would be use collections::Vec;.

[brson]

I haven't seen mention that we would also stop exporting Vec from std. Are we also going to stop exporting Str from std once it becomes a library type? These are pervasive data structures and, while I recognize that it would be nice if all collection-y things were in the collections crate, it also does not strike me as particularly inconsistent that two of the most critical data structures in the language are defined in std.

[emberian]

I also assumed that all collections would be used through collections, and
things would only live in std because functions in std need to use them
(ie, a hack). I don't particularly consider strings a collection, but they
might also live in collections?

On Sat, Mar 15, 2014 at 8:22 PM, Brian Anderson [email protected]:

I haven't seen mention that we would also stop exporting Vec from std.
Are we also going to stop exporting Str from std once it becomes a
library type? These are pervasive data structures and, while I recognize
that it would be nice if all collection-y things were in the collections
crate, it also does not strike me as particularly inconsistent that two of
the most critical data structures in the language are defined in std.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12873#issuecomment-37743841
.

http://octayn.net/

[huonw]

If we're not planning on making collections::Vec the canonical location then I'm not in favour of this change.

(The consistency and backwards compatibility is a factor here too. What if something in std needs TreeMap? Do we move TreeMap into std and reexport from collections, or do we just move it without reexporting? That said, Vec is very core... so I understand that argument.)

(FWIW, I think I would prefer to have a text crate with unicode and decoding/encoding with Str reexported in the same manner.)

[thestinger]

When a user wants an overview of the available collections provided by the standard libraries, they should be able to look in a single module. This module can also be the location of any collection-agnostic documentation and the location of traits like Container. I think it makes a lot more sense than having a separate collections tutorial. Even if Vec is still exported in the standard library, it still improves the documentation.

[liigo]

Vec is a collection, I would like it in or re-export in libcollections.
2014年3月16日 上午8:05于 "Corey Richardson" [email protected]写道：

I support this change.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/12873#issuecomment-37743510
.

[alexcrichton]

Closing due to inactivity. I believe that the story is still developing around Vec<T>, and I would recommend coming to a consensus on #12542 first.

[pnkfelix]

@alexcrichton wait, wasn't the counter-argument presented by @thestinger in #12542 (the counter-argument I took to be his justification for reopening #12542) exactly the proposal being put forth in this issue?