let s1 = String::from("hello world.");
let r1 = &s1;
let sl1 = &s1[..];
let sl2 = &r1[..];
let sl3 = r1[..];
println!("{}", sl3);
What is the difference between sl1 and sl2, and why sl3 is invalid? Isn't r1 a reference already, why need &?
The compiler dereferences the output of Index::index when desugaring the indexing syntax [] (see related question and its answers). Using explicit type annotations, the types of the bindings are thus as follows:
let r1: &str = &s1;
let sl1: &str = &s1[..];
let sl2: &str = &r1[..];
let sl3: str = r1[..];
str, being an unsized type, cannot be put on the stack and therefore cannot be used as the type for a local variable binding sl3, hence the compile error.
Related
What is (&v) actually doing in this code?
let v = vec!["hello", "viktor"];
let mut iterator = (&v).into_iter(); // Iter<&str>
let mut iterator = &v.into_iter(); // &IntoIter<&str>
How it is changing what is returned from .into_iter(). Why is the result different?
This is a precedence issue. With &v.into_iter(), the compiler understands &(v.into_iter()) not (&v).into_iter(), just like when you write 1+2*3, the compiler understands 1+(2*3), and not (1+2)*3.
This question already has an answer here:
Do mutable references have move semantics?
(1 answer)
Closed 1 year ago.
here's my problem:
fn main() {
let mut s = String::from("hello");
let s1 = &mut s;
let s2 = s1;
*s2 = String::from("world1");
*s1 = String::from("world2");
println!("{:?}", s);
}
it will result in a compile error because s1 has type &mut String which doesn't implement the Copy trait.
But if I change the code as below:
fn c(s: &mut String) -> &mut String {
s
}
fn main() {
let mut s = String::from("hello");
let s1 = &mut s;
let s2 = c(s1);
*s2 = String::from("world1");
*s1 = String::from("world2");
println!("{:?}", s);
}
it will compile without any error message.
I know when a reference passed to a function, it means the reference borrows the value insteading of owning it.
But in the situation above, it seems like when s1 was passed to fn c and returned immediatelly, s2 borrowed s1 so s1 couldn't be derefed until s2 was out of it's lifetime scope.
So what happened when s1 was passed into the fn c?
From #Denys Séguret's hint, I guess when s1 was passed to fn C, Rust core compiled the parameter s1 to something like &mut *s1, so there was an immutable borrow of s1.
That's why if we put
*s2 = String::from("world1");
behind
*s1 = String::from("world2");
Rust would tell us:
assignment to borrowed `*s1`
And when s2 goes out of it's lifetime scope, there is no borrow of s1 anymore, so s1 can be derefed again.
But I'm not quite sure whether it's a right explanation.
what is the difference between these two scenario I have the same functionality with 2 different model and it is a bit confusing for me !
//model_1
let mut my_str = String::from("ali");
let str1 = &mut my_str; // defining str1 without "mut"
//model_2
let mut my_str = String::from("ali");
let mut str1 = &mut my_str // defining str1 with "mut"
Let's start with the similarity: neither of them compiles, because you cannot acquire a mutable reference (&mut) of an object that is itself not defined as mut.
As for the correct version, it is the following:
let mut my_str = String::from("ali");
let str2 = &mut my_str;
my_str needs to be defined as mutable if we are to grab a mutable reference to it, so that makes the first line unambiguous.
On the second line, the mut prefix to str2 is only necessary if you are going to modify what reference str2 points to. As long as you are only modifying the content of the string (without changing what string you are modifying) you do not need it.
I am playing around with Rust references:
fn main() {
let str = String::from("Hallo");
let &x = &str;
}
This produces the following error:
error[E0507]: cannot move out of borrowed content
--> src/main.rs:3:9
|
3 | let &x = &str;
| ^-
| ||
| |hint: to prevent move, use `ref x` or `ref mut x`
| cannot move out of borrowed content
What is going on here?
Adding to wiomoc's answer: depending on what language(s) you've previously known, variable declaration in Rust might be a little different. Whereas in C/C++ you explicitly have to declare that you want a pointer/reference variable:
int *p = &other_int;
In Rust it's enough to just use let, so the above would in Rust be
let p = &other_int;
and when you write
let &s = &string;
It pattern-matches that, so the Rust compiler reads it roughly as "I know I have a reference, and I want to bind whatever it is referring to to the name p". If you're not familiar with pattern-matching, a more obvious example (that works in Rust as well) would be
let point = (23, 42);
let (x, y) = point;
The second line unpacks the right-hand side to match the left-hand side (both are tuples of two values) and binds the variable names on the left to the values at the same position in the structure on the right. In the case above, it's less obvious that it's matching your "structural description".
The result of let &x = &str;, i.e. "I know &str is a reference, please bind whatever it refers to to the variable x" means that you're trying to have x be the same as str, when at that line all you have is a borrowed reference to str. That's why the compiler tells you you can't create an owned value (which x would be, because it's not being created as a reference) from a reference.
You dont need that &at let x
let str = String::from("Hallo");
let x = &str;
Or if you want to declare the type manually
let string = String::from("Hallo");
let x: &str = &string;
How could know the type of a binding if I use auto type deduction when creating a binding? what if the expression on the right side is a borrow(like let x = &5;), will it be value or a borrow? What will happen if I re-assign a borrow or a value?
Just for check, I do can re-assign a borrow if I use let mut x: &mut T = &mut T{}; or let mut x:&T = & T{};, right?
I sense some confusion between binding and assigning:
Binding introduces a new variable, and associates it to a value,
Assigning overwrites a value with another.
This can be illustrated in two simple lines:
let mut x = 5; // Binding
x = 10; // Assigning
A binding may appear in multiple places in Rust:
let statements,
if let/while let conditions,
cases in a match expression,
and even in a for expression, on the left side of in.
Whenever there is a binding, Rust's grammar also allows pattern matching:
in the case of let statements and for expressions, the patterns must be irrefutable,
in the case of if let, while let and match cases, the patterns may fail to match.
Pattern matching means that the type of the variable introduced by the binding differs based on how the binding is made:
let x = &5; // x: &i32
let &y = &5; // y: i32
Assigning always requires using =, the assignment operator.
When assigning, the former value is overwritten, and drop is called on it if it implements Drop.
let mut x = 5;
x = 6;
// Now x == 6, drop was not called because it's a i32.
let mut s = String::from("Hello, World!");
s = String::from("Hello, 神秘德里克!");
// Now s == "Hello, 神秘德里克!", drop was called because it's a String.
The value that is overwritten may be as simple as an integer or float, a more involved struct or enum, or a reference.
let mut r = &5;
r = &6;
// Now r points to 6, drop was not called as it's a reference.
Overwriting a reference does not overwrite the value pointed to by the reference, but the reference itself. The original value still lives on, and will be dropped when it's ready.
To overwrite the pointed to value, one needs to use *, the dereference operator:
let mut x = 5;
let r = &mut x;
*r = 6;
// r still points to x, and now x = 6.
If the type of the dereferenced value requires it, drop will be called:
let mut s = String::from("Hello, World!");
let r = &mut s;
*r = String::from("Hello, 神秘德里克!");
// r still points to s, and now s = "Hello, 神秘德里克!".
I invite you to use to playground to and toy around, you can start from here:
fn main() {
let mut s = String::from("Hello, World!");
{
let r = &mut s;
*r = String::from("Hello, 神秘德里克!");
}
println!("{}", s);
}
Hopefully, things should be a little clearer now, so let's check your samples.
let x = &5;
x is a reference to i32 (&i32). What happens is that the compiler will introduce a temporary in which 5 is stored, and then borrow this temporary.
let mut x: &mut T = T{};
Is impossible. The type of T{} is T not &mut T, so this fails to compile. You could change it to let mut x: &mut T = &mut T{};.
And your last example is similar.