Please treat me as a white and introduce me to the whole of [T] and &[T]. I will appreciate your help very much
To me it doesn't make sense to ask someone to write full documentation on a topic, without first at least trying to understand it from the existing documentation, and then asking more specific questions. Have you seen the introductory documentation on arrays and slices in The Book?:
Can you take a look and try to learn this, and then try to ask some questions? Or if you can't learn by reading, please say so and we can probably find some video material.
(Also please note that in English, someone who is "a white" is Caucasian, meaning white skinned and of European origin. I think you meant "treat me as if know nothing".)
It would also help if you can tell us what languages you have learned, and how much Rust programming you have done, if any.
1 Like
Firstly, thank you very much for your response. Your answer was quite helpful to me. I will study your provided link thoroughly.Regarding the expression "a white," I indeed meant "treat me as if unaware of anything." Unfortunately, using this phrasing is apologetic because my English proficiency isn't perfect – it's a translation from another language.
Secondly, why do I have this question in mind? Because I replied that [T] is an array with ownership, while &[T] is a slice without owning.Then he asked me to explain it again, but I don’t know how to respond.Currently, I have previously used Rust to write two crates, both centered around macros.
Of course, I understand.
Thank you for making this more specific, this makes it much easier to have a discussion!
That question can be simplified to ask, in the following code, why is x owned but y is borrowed (not owned)?
let x: usize = 1;
let y: &usize = &x;
The brief answer is: x defines a place where the value 1 is stored. But y references x (it contains the address of x), and does not itself store 1.
If the line with y is removed, x still exists. But if the line with x is removed, y cannot exist and the compiler will report an error.
For arrays and slices, basically the same is true. The diagrams in this section of The Book may help to understand: Variables and Data Interacting with Move.
These diagrams describe a String as the owned object, and a &str slice. The String contains an array of bytes, so it is really the same as the array you asked about.
In fact the whole https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html#understanding-ownership section explains ownership better than I can. Please take a look and ask any questions you have.
You probably already know this, but there are several translations of the The Book into other languages: F - Translations of the Book - The Rust Programming Language
1 Like
Ok. And do you know any other programming languages?
When explaining Rust, sometimes it is easier to explain by making comparisons to other programming languages.
I have read the link you provided, which was very helpful. Now I'll try explaining it; please let me know if my understanding is correct.
let x = 1;
let y = &x;
Is it similar, as in this diagram, on a stack?
I've written Java and C code.
Exactly!
An array ([T; N]) has a length which is known at compile time. The length (N) is part of it's type. An array owns the T within.
+---+---+---+
[u8; 3]: | 0 | 1 | 2 |
+---+---+---+
+---+---+
[u8; 2]: | 0 | 1 |
+---+---+
+---+
[u8; 1]: | 0 |
+---+
[u8; 0]: (no data)
A slice ([T]) is similar, but the length is not known at compile time. We say it is "unsized" or "does not implement Sized" or "is a dynamically sized type (DST)".
+---+---+---+---+---+---+---+---+
[T]: | D | A | T | A | . | . | . | ......
+---+---+---+---+---+---+---+---+
A reference to a slice or a shared slice (&[T]) is a "wide pointer" consisting of a pointer to the slice, and the number of elements in the slice.
+---+---+---+---+---+---+---+---+
&[T]: | Pointer | Length |
+---+---+---+---+---+---+---+---+
|
V
+---+---+---+---+---+---+---+---+
[T]: | D | A | T | A | . | . | . | ......
+---+---+---+---+---+---+---+---+
Shared slices and similar (&[T], &mut [T]) are also often just called "slices" so you have to just figure out if they mean a reference to a slice or a bare, unsized slice from context.
Because they are unsized, you usually see slices ([T]) behind some sort of pointer, be it a reference or something else. Another example is a boxed slice (Box<[T]>):
+---+---+---+---+---+---+---+---+
Box<[T]>: | Pointer | Length |
+---+---+---+---+---+---+---+---+
|
V
+---+---+---+---+---+---+---+---+
[T]: | D | A | T | A | . | . | . | ......
+---+---+---+---+---+---+---+---+
A &[T] does not own the T, but a Box<[T]> does (transitively) own the T.
Should we say [T] owns the T? I would say yes, as to my way of thinking, the T in a Box<[T]> would not have an owner if [T] did not own T. (Box<U> owns U and, transitively, whatever U owns.)
But you could also say "it depends on the entire type".
5 Likes
Your response has taught me a lot.
When I read it again,ch04-03-slices.
I think [T] should be considered as a dynamic collection type.。As we wrote about slicing above, a slice is just a reference – either partial or wholesale – to part of (or all) a collection.So we should call &[T] a reference type。If you follow this slice [T] with shared slices (&[T]), I think I'll confuse them very quickly.
I remember that it took me a moment to really get what a slice (the [T]) actually is. It's a bit abstract. I think of it as some sequence of value T somewhere, without saying where it is or how long it is. It's just multiple T in a row. When you have a pointer to it (like &[T]) you say that it starts at address X and is Y elements long.
If [T; N] is a box, then &[T] is like drawing a circle around a number of items inside the box. If that makes sense.
1 Like
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.