Why rust slice has not ownership?

#1

Is there beacuse slice length is fixed ?slice is a fixed array , it has fixed number of data , so rust save it to the slack , and no need to manage it using ownership?

or slice just a point Essentially ?

#2

By definition. The point of the borrowed slice is not to have ownership. For owned equivalent there’s Box<[T]>, arrays and Vec.

There needs to be a type that allows borrowing of multiple elements of a collection.

Slices can be stored on the heap (eg. Vec<&[T]>) and can be made smaller s = &s[1..];, so it’s not about any technical limitation. It’s the goal in itself.

BTW: If you’re coming from Go, then Go’s slices are a different data type from Rust’s slices. Go slices have shared ownership, so they’re vaguely like Rc<Vec<T>> (but still not quite, as the exact equivalent needs GC).

5 Likes
#3

[T] can own data. That’s precisely what it’s doing in Box<[T]>.

&[T] does not own data, because it is a borrow.

8 Likes
#4

A slice in rust is more abstract than “an object you can own”, instead it’s more like “some data in memory that can be interpreted like a set of Ts”. Therefore, it is not something that you can simply “own” without a pointer, because it is simply continuous data, and is made to be worked with behind a pointer of some sort. That pointer can be an owning pointer (Box<[T]>) or a non-owning pointer (&[T] or &mut [T]). When you say [T] in rust, you really mean, some continuous data, which has no real defined size, because the size is not encoded in the [T] type, instead it is encoded in the &[T] type which is special.

Lets say I could own a [T]:

let x: [usize] = [1, 2, 3];

Then what could I do with it? Really, nothing right now*, because:

  • It has no defined size, and can therefore not live on the stack right now*
  • Once again, you could do no panic-safe operations due to there not being a length of the data, and no feasible way to check it without some UB (I’m not too sure, but I believe that poking memory to see if I own it is UB), and even then, there would be no guarantee that the next size_of::<usize>() bytes can even be safely interpreted as a usize right now*
  • And last but not least, the non-existent size comes to bite us again, when getting rid of this memory (dropping it), there is no way to tell when we should stop de-allocating, again, this is UB. right now*

Also, don’t mix up arrays ([T; n]) and slices ([T]). Arrays have a constant size defined at compile time, and are therefore constant throughout the program, and can be properly allocated size on the stack (And owned without a pointer).


*There is an rfc mentioned in the next post in this thread which aims to change all of this, so this really only applies right now, and may become invalid in some time (Years, or months) depending on the rust team’s focuses

3 Likes
#5

Sure you could. It can be allocated using alloca, as described in RFC 1909.

1 Like
#6

thanks guys. I new to rust , just from golang , what u were said is meaning , I need to comprehend a while.

#7

Welcome to Rust! It’s different, but much less malware-prone than other languages. Don’t hesitate to post in this forum; you’ll almost always get a number of timely, friendly responses. :grinning:

3 Likes