Use explicit range when slicing into string

[randomPoison]

I don't like the &s2[s2.len() - s1.len()..] index operation because it's always hard for me to scan and explain, and I don't want to be focusing on the math, I want to focus on the slice operation. I think it would be better to use an explicit range so we can keep things simple and clear for students. I also never liked that s3 is "World", since that's also what s1 was, so I don't feel it clearly enough demonstrates that s3 is coming from s2. I think pulling a weird range out of the middle of s2 would better show that we're indeed looking at part of the full string. Now s3 is "llo Wor".

[djmitche]

I remember being confused about this too!

[fw-immunant]

Hm, I usually took this slide as an opportunity to emphasize that an &str could point into a string literal or a heap-allocated String while comparing equal. I do agree that the index logic did take some staring at to figure out, though.

[randomPoison]

Hm, I usually took this slide as an opportunity to emphasize that an &str could point into a string literal or a heap-allocated String while comparing equal.

Oh interesting, I never talk about string equality here. I don't think I talk about equality until the stdlib section where we talk about operator overloading. And now that I think about it, I don't usually remember to point out value equality vs reference equality when I get there. I think I'll add a speaker note about that, hopefully that'd also give you a chance to talk about this kind of equality comparison?

[randomPoison]

@fw-immunant I've opened #2670 to add a speaker note to call out the behavior of reference equality in Rust, lmk if that addresses your concern here.