Can the usual closed-interval version panic in Rust?

Yes, on the empty vector: let mut hi = nums.len() - 1 subtracts on usize, so search(vec![], 3) panics with "attempt to subtract with overflow" in a debug build before the loop starts. In this particular search hi = mid - 1 only runs when mid > lo, but in an ordinary binary search it runs at mid == 0 too and underflows the same way. The half-open window lo..hi (shrink with hi = mid) has no subtraction to worry about; the other fix is signed i32 bounds cast to usize only to index.

Why lo + (hi - lo) / 2 instead of (lo + hi) / 2?

lo + hi can overflow when the two indices are near usize::MAX, which panics in a debug build. That never happens with 5,000 elements, but lo + (hi - lo) / 2 costs nothing and is always safe.

What does slice::binary_search return?

Result : Ok(i) with the index of a match, or Err(i) with the index where the value would be inserted to keep the slice sorted. Here only Ok matters, and its index is relative to the slice, so it is added to start.

Can I call nums.binary_search(&target) on the whole vector?

No. A rotated vector is not sorted, and binary_search on unsorted data returns an unspecified result: on [15, 22, 30, 4, 9, 11] it can report 4 as missing. Split at the rotation point first, or use the one-pass search. partition_point(|&n| n > nums[nums.len() - 1]) is another way to find the rotation point.

Why does the signature take Vec and not &[i32]?

The signature is fixed by the harness and takes ownership of the vector. Inside, every slice method still works because Vec derefs to [i32]: nums[start..end].binary_search(&target) borrows a sub-slice without copying.

Search in Rotated Sorted Array in Rust: Scan and Binary Search Solutions

search.rs

Rust 1.98

Not run yet

+ 8 hidden

Input

nums = [15, 22, 30, 4, 9, 11]
target = 9

Expected

This is [4, 9, 11, 15, 22, 30] rotated so it starts at 15. The 9 sits at index 4.