What is the difference between a slice and an array?

Question

Why are both &[u8] and &[u8; 3] ok in this example?

fn main() {
    let x: &[u8] = &[1u8, 2, 3];
    println!("{:?}", x);

    let y: &[u8; 3] = &[1u8, 2, 3];
    println!("{:?}", y);
}

The fact that &[T; n] can coerce to &[T] is the aspect that makes them tolerable. — Chris Morgan

Why can &[T; n] coerce to &[T]? In what other conditions does this coercion happen?

score 54 · Accepted Answer · edited May 13 '18 at 19:12

[T; n] is an array of length n, represented as n adjacent T instances.

&[T; n] is purely a reference to that array, represented as a thin pointer to the data.

[T] is a slice, an unsized type; it can only be used through some form of indirection.

&[T], called a slice, is a sized type. It's a fat pointer, represented as a pointer to the first item and the length of the slice.

Arrays thus have their length known at compile time while slice lengths are a runtime matter. Arrays are second class citizens at present in Rust, as it is not possible to form array generics. There are manual implementations of the various traits for [T; 0], [T; 1], &c., typically up to 32; because of this limitation, slices are much more generally useful. The fact that &[T; n] can coerce to &[T] is the aspect that makes them tolerable.

There is an implementation of fmt::Debug for [T; 3] where T implements Debug, and another for &T where T implements fmt::Debug, and so as u8 implements Debug, &[u8; 3] also does.

Why can &[T; n] coerce to &[T]? In Rust, when does coercion happen?

It will coerce when it needs to and at no other times. I can think of two cases:

where something expects a &[T] and you give it a &[T; n] it will coerce silently;
when you call x.starts_with(…) on a [T; n] it will observe that there is no such method on [T; n], and so autoref comes into play and it tries &[T; n], which doesn’t help, and then coercion come into play and it tries &[T], which has a method called starts_with.

The snippet [1, 2, 3].starts_with(&[1, 2]) demonstrates both.

Regarding coercion, I'm a little confused. For example, the Pattern trait is implemented for &[char]. I make a variable x = [' '] and try to use &x as a pattern (e.g. pass it to trim_matches on a String), but this results in compiler error. I can see the type of x is &[char, 1]. If I try to pass &x[..] it gets forced into &[char] and now the compiler finds the Pattern implementation. Is there something I'm missing or is this &[T; n] -> &[T] coercion not checked when looking for trait implementations? — Giedrius Kudelis, Jul 17 '19 at 10:02
What I say may not be completely correct, but it is my understanding: Generic implementations have a nasty habit of getting in the way of coercions, because they’re essentially ranked as more important than array-to-slice coercion. It sees that all types satisfying `FnMut(char) -> bool` implement the trait, and so stops there, trying to satisfy that trait bound rather than playing around with type coercions. With const generics, this could be resolved by manually providing a `[char; N]` and/or `&[char; N]` implementation (`impl`). Whether it will be is another matter. — Chris Morgan, Jul 29 '19 at 14:38

score 18 · Answer 2 · edited May 13 '18 at 19:13

Why can &[T; n] coerce to &[T]?

The other answer explains why &[T; n] should coerce to &[T], here I'll explain how the compiler works out that &[T; n] can coerce to &[T].

There are four possible coercions in Rust:

Transitivity.
- If T coerces to U and U coerces to V, then T coerces to V.
Pointer weakening:
- removing mutability: &mut T → &T and *mut T → *const T
- converting to raw pointer: &mut T → *mut T and &T → *const T
Deref trait:
- If T: Deref<Target = U>, then &T coerces to &U via the deref() method
- (Similarly, if T: DerefMut, then &mut T coerces to &mut U via deref_mut())
Unsize trait:
- If Ptr is a "pointer type" (e.g. &T, *mut T, Box, Rc etc), and T: Unsize<U>, then Ptr<T> coerces to Ptr<U>.
- The Unsize trait is automatically implemented for:
  - [T; n]: Unsize<[T]>
  - T: Unsize<Trait> where T: Trait
  - struct Foo<…> { …, field: T }: Unsize< struct Foo<…> { …, field: U }>, provided that T: Unsize<U> (and some more conditions to make the job easier for the compiler)
- (Rust recognizes Ptr<X> as a "pointer type" if it implements CoerceUnsized. The actual rule is stated as, “if T: CoerceUnsized<U> then T coerces to U”.)

The reason &[T; n] coerces to &[T] is rule 4: (a) the compiler generates the implementation impl Unsize<[T]> for [T; n] for every [T; n], and (b) the reference &X is a pointer type. Using these, &[T; n] can coerce to &[T].

score 9 · Answer 3 · edited Dec 20 '21 at 16:37

9

I created this picture according to the answers of kennytm and Chris Morgan. It describes the various concepts:

edited Dec 20 '21 at 16:37

Shepmaster

388,571
95
1,107
1,366

answered Mar 08 '19 at 06:06

keroro520

459
4
12

10

`n` does not exist in memory. For a slice, it’s in the fat pointer, but for an array or array reference, it exists only in the type, as `N`; it is all sorted out at compile time and does not appear at runtime at all. – Chris Morgan Jul 29 '19 at 14:43
1

This is otherwise a super helpful illustration! I wish more people used visual aids when explaining concepts. – Cypress Frankenfeld Feb 03 '22 at 01:12

What is the difference between a slice and an array?

3 Answers3

Linked

Related