DEV Community: Jazz Thumyat 🦀

Why Does `Box<[T]>` Support `iter()` But `Box` Doesn't?

Jazz Thumyat 🦀 — Tue, 30 Jun 2026 12:31:45 +0000

Have you ever wondered why you can call iter() on Box<[T]>?

For example:

let nums = vec![1, 2, 3, 4, 5];  
let box_of_slice : Box<[i32]> = nums.into_boxed_slice();  
for n in box_of_slice.iter() {  
    println!("{}", n);  
}

box_of_slice is of type Box<[i32]>, and we can iterate over it. The reason is that Box<T> implements Deref<Target = T>. Rust automatically follows the deref chain until it reaches a type that has the iter() method.

Box<[i32]>  →  deref  →  [i32]  →  has .iter()

But for Box<i32>, we can't call iter() because i32 isn't iterable.

Box<i32>    →  deref  →  i32    →  no .iter()

i32 is a scalar with no concept of iteration. Once Box<i32> dereferences to i32, there's no iter() method to call. This is why deref coercion in Rust is so powerful—Box<T> can act like T in terms of available methods, but only if T actually supports them.

How Rust Decides Whether an Array Is Copy

Jazz Thumyat 🦀 — Sat, 27 Jun 2026 15:03:05 +0000

In Rust, we all know that Vec is not Copy, which means it does not implement the Copy trait. As a result, after iterating over a Vec like this:

let num = vec![1, 2, 3];

for i in num {
    println!("{}", i);
}

println!("{:?}", num); // compiler error: value borrowed here after move

the compiler reports an error because num has been moved. When we write for i in num, Rust desugars it into something like for i in num.into_iter(). The into_iter method takes self by value:

#[inline]
fn into_iter(self) -> Self::IntoIter {
    // ...
}

Because Vec<T> is not Copy, passing it by value moves it into the iterator. Ownership is transferred to the iterator, so num can no longer be used after the loop.

Now let’s try the same thing with an array:

let num = [1, 2, 3];

for i in num {
    println!("{}", i);
}

println!("{:?}", num); // works

There is no compiler error this time. Why?

The type of num is [i32; 3]. Since i32 implements Copy, the array also implements Copy. That means num is copied into the loop instead of being moved, and the original array remains available after the loop.

Now consider an array of Strings:

let strs = ["one".to_string(), "two".to_string()];

for s in strs {
    println!("{}", s);
}

println!("{:?}", strs); // compiler error: value borrowed here after move

This produces the same compiler error as the Vec example.

The reason is that String does not implement Copy. As a result[String; 2] is also not Copy. When the array is passed to into_iter, it is moved into the iterator, making strs unavailable afterward.

So how does Rust know that some arrays are Copy while others are not?

This isn’t compiler magic. It’s implemented in the standard library with a blanket implementation:

impl<T: Copy, const N: usize> Copy for [T; N] {}

This implementation says:

For any type T that implements Copy, and for any array length N, the array [T; N] also implements Copy.

As a result:

[i32; 3] is Copy because i32 is Copy.
[bool; 10] is Copy because bool is Copy.
[String; 2] is not Copy because String is not Copy.

In other words, whether an array implements Copy depends entirely on whether its element type implements Copy.

Understanding `&mut &'a self` Calls on Temporaries in Rust

Jazz Thumyat 🦀 — Fri, 26 Jun 2026 13:25:04 +0000

[T] has the following split_off method. Notice that its receiver type is &mut &'a Self:

pub fn split_off<'a, R: OneSidedRange<usize>>(
    self: &mut &'a Self,
    range: R,
) -> Option<&'a Self> {
    // ...
}

Now look at this code:

let v = vec![1, 2, 3, 4, 5];
let head = v.as_slice().split_off(..2);

assert_eq!(head, Some([1, 2].as_slice()));

This may look confusing at first.

v.as_slice() returns &[i32], but split_off() expects &mut &[i32]. So where does the mutable reference come from?

The answer is that v.as_slice() creates a temporary value. In Rust, a temporary is a mutable place, so the compiler can automatically borrow it as &mut.

You can think of the code as if the compiler had written this:

let mut temp = v.as_slice();
temp.split_off(..2);

The mutable reference is taken to the temporary variable (temp), not to the original vector or slice. The vector v and the slice it produces are never mutated. Only the temporary variable is.

Proof that temporaries are mutable places

A normal let binding is immutable unless you write mut. Because of that, the following code does not compile:

let s: &[i32] = v.as_slice(); // no `mut`
let _ = s.split_off(..2);     // compiler error here

The compiler reports:

error[E0596]: cannot borrow `s` as mutable, as it is not declared as mutable
13 |     let _ = s.split_off(..2);
   |             ^ cannot borrow as mutable
help: consider changing this to be mutable
12 |     let mut s: &[i32] = v.as_slice();

This shows the difference:

let s: &[i32] = v.as_slice() creates an immutable place, so Rust cannot take &mut s.
v.as_slice() creates a temporary, and a temporary is a mutable place, so Rust can automatically take &mut to call split_off().

That is why v.as_slice().split_off(..2) compiles, while s.split_off(..2) does not unless s is declared with mut.

Expected Option, Got Option<()> — Here's Why

Jazz Thumyat 🦀 — Thu, 25 Jun 2026 04:24:16 +0000

I'm learning Rust and recently ran into something unexpected with Option type. I expected r to be Option<&mut String>, but it came back as Option<()> instead.

Here's what I tried:

let mut vds = VecDeque::from(["a".to_owned(), "b".to_owned()]);  
let r = vds  
    .get_mut(0)  
    .and_then(|v| Some(*v = String::from("Hello")));

It turned out to be a fundamental Rust concept: assignment is an expression, and it always evaluates to (), the empty unit type.

Here's why: *v = String::from("Hello") is an assignment, so it evaluates to (). Some() wraps that unit value, giving us Some(()). That's why r ends up as Option<()>.