Rust 1.53 adds owned array iteration with a compatibility exception

Adding a trait implementation can change the meaning of code that already compiles. Rust 1.53's owned array iteration illustrates the problem. Arrays now implement IntoIterator, yet the compiler deliberately avoids using that implementation for one familiar method-call spelling in existing editions. The exception preserves code that previously reached an iterator over references through automatic borrowing.

The June 17 release announcement explains the distinction. A for loop can consume an array by value, and an array can be passed directly where an IntoIterator is required. An array's .into_iter method call retains its earlier reference behavior. The difference is syntax-specific, not a partial implementation of the trait.

I find this interesting because ownership is part of what makes Rust declarations useful. An iterator yielding an owned String and an iterator yielding a reference to String impose different obligations on their consumers. Preserving that distinction in existing code is a substantive compatibility concern.

The earlier call borrowed the array

Before this release, references to arrays implemented IntoIterator. Consequently, writing array.into_iter could compile by resolving to an invocation on a reference to the array. A direct array implementation would provide a new candidate with different ownership behavior. Existing source could then select a different operation after a compiler upgrade.

The new release includes the direct implementation but preserves the old resolution for this particular method-call syntax. The announcement describes the compiler behaving as though the array implementation did not exist for that call. It does not withhold the implementation from other uses of the trait.

That distinction makes the compatibility choice precise. A generic function requiring IntoIterator can receive an array. Iterator combinators can receive arrays where their argument bounds permit it. Fully qualified IntoIterator::into_iter also uses the owned implementation. The retained behavior belongs specifically to method-call resolution on arrays in existing editions.

The announcement says the exception is scheduled to disappear in Rust 2021 later this year. On this release date, that is a planned edition difference. It is not a reason to describe ordinary existing-edition .into_iter calls as already consuming their array elements.

The explicit trait call shows ownership

This example uses fully qualified trait syntax, one of the forms the release announcement identifies as using the new implementation. The loop receives owned strings from the array.

let labels = [String::from("ready"), String::from("waiting")];
for label in IntoIterator::into_iter(labels) {
    let owned: String = label;
    println!("{}", owned);
}

The explicit String annotation makes the item type visible in the example. A reference iterator could not supply that owned value through the assignment. The point is the ownership relationship, so choosing a non-Copy element type makes it easier to see than an example containing only integers.

Generic iterator consumers benefit without needing an array-specific constructor in their own implementation. The announcement gives chain and zip as examples of methods that can now accept arrays directly. Their input requirement is the trait, so supplying the array lets the consumer obtain the appropriate iterator through that contract. A caller can express a short fixed sequence as an array and still compose it with another iterator. This is a different improvement from changing the item type of an existing method call. The library gains another valid input while the compiler preserves the older call's resolution where compatibility requires it.

Rust 1.51 had already provided an owned array iterator through std::array::IntoIter::new, as its March announcement explains. The new capability is the array's trait implementation and its resulting integration with generic iterator consumers. Owned array iteration did not first become possible in June.

This progression is useful history for library authors. An explicit constructor can make a capability available before a compatible trait integration is ready. The later implementation then reduces the special handling required by generic code. The compatibility exception explains why the shortest apparent syntax cannot change at exactly the same time.

Nested alternatives reduce repeated structure

Rust 1.53 also permits or-patterns nested inside other patterns. A match can place alternatives at the part that varies instead of repeating the surrounding structure. The release gives Some containing either one or two as a simple case.

fn is_small_present(value: Option<u8>) -> bool {
    match value {
        Some(1 | 2) => true,
        _ => false,
    }
}

This describes the same alternatives that would previously require repeating Some around each value. The match still has an explicit fallback. Nesting expresses a local choice inside a shared structure, which becomes more useful as that surrounding structure grows.

The release announcement illustrates alternatives inside both an Ok-wrapped option and an error structure. These examples show that the extension belongs to pattern syntax generally. It is not a special-purpose shorthand for matching small integers or options.

I like this change because it can make the structure being matched easier to inspect. Repeating the outer pattern forces a reader to compare several copies before locating the actual difference. A nested alternative puts that difference at the relevant field or payload.

Identifier support follows Unicode rules

The release also stabilizes non-ASCII identifiers according to Unicode's identifier rules in UAX 31. The announcement notes that scripts from many languages are supported while emoji are not valid identifier characters. Supporting Unicode identifiers does not mean accepting every visible Unicode symbol as a name.

The compiler also warns about potentially confusing combinations, including visually similar identifiers from different scripts. That matters because a name's appearance and its encoded identity can differ. The language extension expands the naming vocabulary while diagnostics address some risks of confusingly similar spellings.

Other maintenance details remain relevant to the release's interpretation. Cargo no longer assumes a Git repository's default HEAD is named master. Incremental compilation remains disabled by default on stable, following the 1.52.1 workaround. The release announcement explicitly preserves that setting rather than claiming the new language features imply a restoration of incremental behavior.

For array users, the immediate change is integration with consumers of IntoIterator. Understanding which syntax selects the owned implementation prevents a mistaken ownership assumption. The new nested patterns address a separate readability problem by keeping shared pattern structure in one place, while both changes preserve the explicit relationships that Rust code asks a reader to follow.