Uh, what ever happened to subslice patterns?

A long time ago (okay maybe not that long ago), there was a proposal for something along the lines of:

fn get_base(x: &[u8]) -> usize {
  match x {
    [..b"0x", ..] => 16,
    [..b"0o", ..] => 8,
    [..b"0b", ..] => 2,
    _ => 10,

but from what we can tell it never went any further than existing as a proposal? What happened to it? (We know this syntax, ..b"foo", conflicts with ranges, so we wouldn't expect subslice patterns to use this syntax nowadays, but anyway...)

Stablized in Rust 1.42.


Keep in mind that [x, y], [.., x], [x, ..] and [x, .., y] are valid, but [.., x, ..] and [.., x, .., y, ..] are not.

Yes, those require you to spell it out as [b'f', b'o', b'o', ..] and have fun with unicode.

There was also something about nesting subslice patterns, a la [..[1, 2, 3], 4, 5], but we can't find anything like it anywhere around stabilization and it doesn't seem to be currently supported in nightly either.

Let's say you have some MAGIC_VALUEs of various lengths.

const JAVA_MAGIC: [u8; 4] = b"\xCA\xFE\xBA\xBE";
const GIF_MAGIC: [u8; 6] = b"GIF89a";

and you want to match them:

match file_bytes {

in an ideal world you'd be able to use subslice patterns for that:

match file_bytes {
  [..JAVA_MAGIC, rest @ ..] => decode_java(rest),
  [..GIF_MAGIC, rest @ ..] => decode_gif(rest),

Looks like it was mentioned, perhaps if there's enough interest it could be revived.

1 Like


We don't know how to update structs in current Rust, but we'd like to propose the alternative syntax:

RangeTo { ..: ..10 }

because it conceptually makes sense ("all other fields take from this other value" or something).

Then we can extend this syntax to arrays, to match patterns, and then to subslice patterns. Thoughts?

1 Like

This is already possible, with the shorter syntax RangeTo { ..(..10) }. (You can even say RangeTo { .. ..10 }, but that looks confusing :stuck_out_tongue: )


The proposed syntax (with the :) would be more compatible with subslice subpatterns, and the thing with arrays. But fair enough.