4 ms·
There's definitely a theory that the pairs of view and buffer (or borrowing and owning) types should have been more consistently named. I think steveklabnik usu
by twic 6y ago
There's definitely a theory that the pairs of view and buffer (or borrowing and owning) types should have been more consistently named. I think steveklabnik usually manifests in these threads to express it. But it's something like:
str is to String
as &[] is to Vec
as Path is to PathBuf
... and the names should reflect that.
- steveklabnik 6y agoYep, you nailed it. I wouldn't change Vec though. I would make the string types more consistent with the path types. The reason is that slices are more general than just vectors, whereas str/String and Path/PathBuf are virtually always only used together.
- twic 6y agoFair enough. Although i'd rename Vec to List, because variable-length sequences are not vectors, and there's no need to propagate that mistake any further!
- steveklabnik 6y agoThe problem is, some people think List means some form of linked list, not what a vector is. Names are hard.
- baby 6y agoIt’s not totally true right? &Vec would be the equivalent here, what you pointed to can only be obtained by doing vec.as_slice()
- steveklabnik 6y agoThat is not correct, &Vec is fundamentally different. &str, &[T], and &Path are all "a pair of a pointer and a length," and String, Vec<T>, and PathBuf are all "a triple of a pointer, a length, and a capacity.". &Vec<T> is "a pointer to a triple of a pointer, a length, and a capacity."
- baby 6y agoI guess I’m a bit confused sometimes as what you get when you borrow. Sometimes I can borrow, sometimes I need to call .as_slice() or as_path or as_str
- steveklabnik 6y agoYeah, so thanks to “Deref coercion” a &Vec<T> will coerce into a &[T] in many places. That’s probably what you’re seeing.