Fix slices immutable example

[papigers]

The question "What happens if you modify a[3]?", aims to teach the reader that we cannot mutate the array after creating a slice. However, the array is immutable regardless. Running the edited example:

fn main() {
    let a: [i32; 6] = [10, 20, 30, 40, 50, 60];
    println!("a: {a:?}");

    let s: &[i32] = &a[2..4];
    a[3] = 0;
    println!("s: {s:?}");
}

will return the following output:

   Compiling playground v0.0.1 (/playground)
error[E0594]: cannot assign to `a[_]`, as `a` is not declared as mutable
 --> src/main.rs:6:5
  |
6 |     a[3] = 0;
  |     ^^^^^^^^ cannot assign
  |
help: consider changing this to be mutable
  |
2 |     let mut a: [i32; 6] = [10, 20, 30, 40, 50, 60];
  |         +++

error[E0506]: cannot assign to `a[_]` because it is borrowed
 --> src/main.rs:6:5
  |
5 |     let s: &[i32] = &a[2..4];
  |                      - `a[_]` is borrowed here
6 |     a[3] = 0;
  |     ^^^^^^^^ `a[_]` is assigned to here but it was already borrowed
7 |     println!("s: {s:?}");
  |                   - borrow later used here

Some errors have detailed explanations: E0506, E0594.
For more information about an error, try `rustc --explain E0506`.
error: could not compile `playground` due to 2 previous errors

While the error explains both issues (assignment to an immutable value and assignment to a borrowed value), I think it would be better to make the array mutable to better understand the limitation.

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[mgeisler]

Hi @papigers, thanks for the PR.

The question "What happens if you modify a[3]?", aims to teach the reader that we cannot mutate the array after creating a slice.

I see what you mean... However, thinking back, I think my original point here was that the slice reflects the updated array if you write to it (since it's a view).

I normally spend some time showing the read-only slice before I go on to talk about the mutating case. I add the mut when we reach that point. The speaker notes don't make that very clear at all and we could perhaps make it more clear what the instructor should focus on? I'm always happy to expand these notes.

[papigers]

I do imagine that going over the course with an instructor, the issue is less apparent or impactful, but as I "took" the course online and without an instructor, I found the error message to be confusing (not mind boggling, but still confusing).

I think that because, at this stage, the subject of variable mutability is already covered - the error message is a distraction from the "real" new lesson here.

I would also say that regardless of whether the rust compiler finds the assignment as valid or not, it would make sense to declare the variable as mutable (as the code attempts to mutate it).

[mgeisler]

I think that because, at this stage, the subject of variable mutability is already covered - the error message is a distraction from the "real" new lesson here.

Okay, that argument makes sense to me. I've approved the PR!