Slice syntax in Rust - Time & Space Complexity
We want to understand how the time it takes to work with slices changes as the slice size grows.
Specifically, how does accessing or iterating over a slice behave as it gets bigger?
Analyze the time complexity of the following code snippet.
fn sum_slice(slice: &[i32]) -> i32 {
let mut total = 0;
for &item in slice {
total += item;
}
total
}
This code adds up all the numbers in a slice of integers.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each element in the slice.
- How many times: Once for every element in the slice.
As the slice gets bigger, the number of additions grows in the same way.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 additions |
| 100 | 100 additions |
| 1000 | 1000 additions |
Pattern observation: The work grows directly with the number of items.
Time Complexity: O(n)
This means the time to sum the slice grows in a straight line as the slice gets bigger.
[X] Wrong: "Accessing a slice element takes longer as the slice grows."
[OK] Correct: Accessing any single element by index is fast and does not depend on slice size. Only looping over all elements takes longer as the slice grows.
Understanding how slice operations scale helps you explain how your code handles data efficiently, a key skill in many programming tasks.
"What if we changed the loop to only sum the first half of the slice? How would the time complexity change?"
Practice
&array[2..5] mean in Rust?Solution
Step 1: Understand slice range syntax
The syntaxstart..endmeans fromstartindex up to but not includingendindex.Step 2: Apply to given slice
So&array[2..5]means elements at indices 2, 3, and 4 are included in the slice.Final Answer:
It creates a view of elements from index 2 up to but not including 5. -> Option AQuick Check:
Slice range excludes end index = A [OK]
- Thinking the slice copies elements instead of borrowing
- Including the end index element in the slice
- Confusing slice with single element access
nums?Solution
Step 1: Identify slice start and end for first 4 elements
The first 4 elements are at indices 0, 1, 2, and 3, so slice should start at 0 and end at 4 (exclusive).Step 2: Check options for correct syntax
&nums[0..4] uses&nums[0..4], which correctly slices elements 0 to 3.Final Answer:
&nums[0..4] -> Option BQuick Check:
Slice first 4 elements = &nums[0..4] [OK]
- Starting slice at 1 instead of 0
- Including one extra element by using end index too high
- Using reversed range which is invalid
let arr = [10, 20, 30, 40, 50];
let slice = &arr[1..4];
println!("{:?}", slice);Solution
Step 1: Identify slice indices and elements
The slice&arr[1..4]includes elements at indices 1, 2, and 3, which are 20, 30, and 40.Step 2: Understand print output
Printing the slice with{:?}shows the elements in array-like format.Final Answer:
[20, 30, 40] -> Option CQuick Check:
Slice arr[1..4] = [20, 30, 40] [OK]
- Including element at index 4 mistakenly
- Printing the whole array instead of slice
- Confusing slice with copying elements
let arr = [1, 2, 3, 4]; let slice = &arr[3..2];
Solution
Step 1: Analyze slice indices order
The slice&arr[3..2]has start index 3 and end index 2, which is invalid because start must be less than or equal to end.Step 2: Understand Rust slice behavior
Rust panics at runtime if slice start is greater than end; it does not return empty slice or reorder indices.Final Answer:
The slice start index is greater than the end index, causing a panic. -> Option AQuick Check:
Slice start > end causes panic [OK]
- Assuming reversed slice returns empty slice
- Thinking slice silently swaps indices
- Using parentheses instead of brackets for slices
let text = "hello world";, which slice expression extracts the word "world" correctly?Solution
Step 1: Identify indices of "world" in the string
"hello world" has "world" starting at index 6 and goes to the end (index 10 inclusive).Step 2: Check slice options
&text[6..] uses&text[6..]which means from index 6 to the end, correctly extracting "world".Final Answer:
&text[6..] -> Option DQuick Check:
Slice from start index to end = &text[6..] [OK]
- Using wrong end index excluding last character
- Confusing byte indices with character indices (not in this example)
- Using slice that extracts wrong substring
Ready to prove it?
Pass the test and this pattern moves unknown
