Stabilization proposal

This PR proposes the stabilization of #![feature(let_chains)] in a future-compatibility way that will allow the possible addition of the EXPR is PAT syntax.

Tracking issue: #53667
Version: 1.62 (2022-05-17 => beta, 2022-06-30 => stable).

What is stabilized

The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example:

pub enum Color {
    Blue,
    Red,
    Violet,
}

pub enum Flower {
    Rose,
    Tulip,
    Violet,
}

pub fn roses_are_red_violets_are_blue_printer(
    (first_flower, first_flower_color): (Flower, Color),
    (second_flower, second_flower_color): (Flower, Color),
    pick_up_lines: &[&str],
) {
    if let Flower::Rose = first_flower
        && let Color::Red = first_flower_color
        && let Flower::Violet = second_flower
        && let Color::Blue = second_flower_color
        && let &[first_pick_up_line, ..] = pick_up_lines
    {
        println!("Roses are red, violets are blue, {}", first_pick_up_line);
    }
}

fn main() {
    roses_are_red_violets_are_blue_printer(
        (Flower::Rose, Color::Red),
        (Flower::Violet, Color::Blue),
        &["sugar is sweet and so are you"],
    );
}

Motivation

The main motivation for this feature is improving readability, ergonomics and reducing paper cuts.

For more examples, see the RFC.

What isn't stabilized

• Let chains in match guards (if_let_guard)

• Resolution of divergent non-terminal matchers

• The EXPR is PAT syntax

History

From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-06-30), it can be said that this feature took 4 years, 6 months and 7 days of research, development, discussions, agreements/consensus and headaches to be settled.

Divergent non-terminal matchers

More specifically, #86730.

macro_rules! mac {
    ($e:expr) => {
        if $e {
            true
        } else {
            false
        }
    };
}

fn main() {
    // OK!
    assert_eq!(mac!(true && let 1 = 1), true);

    // ERROR! Anything starting with `let` is not considered an expression
    assert_eq!(mac!(let 1 = 1 && true), true);
}

To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider let an expression.

It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers.

Alternative syntax

Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, let PAT = EXPR will be utilized for stabilization but it doesn't or shall create any obstacle for a possible future addition of EXPR is PAT.

The introductory snippet would then be written as the following.

if first_flower is Flower::Rose 
    && first_flower_color is Color::Red
    && second_flower is Flower::Violet
    && second_flower_color is Color::Blue
    && pick_up_lines is &[first_pick_up_line, ..]
{
    println!("Roses are red, violets are blue, {}", first_pick_up_line);
}

Just to reinforce, this PR only unblocks a possible future road for EXPR is PAT and does emphasize what is better or what is worse.

Tests

Most of the infra-structure used by let chains is also used by if expressions in stable compiler versions since #80357 and #88572. As a result, no bugs were found since the integration of #88642.

Possible future work

• Let chains in match guards is implemented and working but stabilization is blocked by if_let_guard.

• The usage of let_chains with let_else is possible but not implemented. Regardless, one attempt was introduced and closed in #93437.

Thanks @Centril for creating the RFC and huge thanks (again) to @matthewjasper for all the reviews, mentoring and MIR implementations.

Fixes #53667