[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains by Centril · Pull Request #60861 · rust-lang/rust (original) (raw)

Centril

Centril

bors added a commit that referenced this pull request

May 15, 2019

@bors

[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains

Here we remove ast::ExprKind::{IfLet, WhileLet} and introduce ast::ExprKind::Let. Moreover, we also:

However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR.

Per #53667 (comment). Next step after #59288.

cc @Manishearth re. Clippy.

r? @oli-obk

@bors bors added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

May 15, 2019

bors added a commit that referenced this pull request

May 16, 2019

@bors

[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains

Here we remove ast::ExprKind::{IfLet, WhileLet} and introduce ast::ExprKind::Let. Moreover, we also:

However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR.

Per #53667 (comment). Next step after #59288.

cc @Manishearth re. Clippy.

r? @oli-obk

@bors bors added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

May 16, 2019

bors added a commit that referenced this pull request

Jun 23, 2019

@bors

Remove ast::Guard

With the introduction of ast::ExprKind::Let in #60861, the ast::Guard structure is now redundant in terms of representing if let guards in AST since it can be represented by ExprKind::Let syntactically. Therefore, we remove ast::Guard here.

However, we keep hir::Guard because the semantic representation is a different matter and this story is more unclear right now (might involve goto 'arm in HIR or something...).

r? @petrochenkov

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Jun 23, 2019

bors added a commit that referenced this pull request

Jun 23, 2019

@bors

[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains

Here we remove ast::ExprKind::{IfLet, WhileLet} and introduce ast::ExprKind::Let. Moreover, we also:

However, this does not connect the new syntax to semantics in HIR. That will be the subject of a subsequent PR.

Per #53667 (comment). Next step after #59288.

cc @Manishearth re. Clippy.

r? @oli-obk

Centril added a commit to Centril/rust that referenced this pull request

Jun 23, 2019

@Centril

…rochenkov

Remove ast::Guard

With the introduction of ast::ExprKind::Let in rust-lang#60861, the ast::Guard structure is now redundant in terms of representing if let guards in AST since it can be represented by ExprKind::Let syntactically. Therefore, we remove ast::Guard here.

However, we keep hir::Guard because the semantic representation is a different matter and this story is more unclear right now (might involve goto 'arm in HIR or something...).

r? @petrochenkov

@Centril Centril deleted the let-chains-ast-intro branch

June 23, 2019 15:15

This was referenced

Jun 23, 2019

bors added a commit that referenced this pull request

Jun 24, 2019

@bors

Remove ast::Guard

With the introduction of ast::ExprKind::Let in #60861, the ast::Guard structure is now redundant in terms of representing if let guards in AST since it can be represented by ExprKind::Let syntactically. Therefore, we remove ast::Guard here.

However, we keep hir::Guard because the semantic representation is a different matter and this story is more unclear right now (might involve goto 'arm in HIR or something...).

r? @petrochenkov

bors added a commit to rust-lang/rust-clippy that referenced this pull request

Jun 24, 2019

@bors

Fix fallout from rust-lang/rust PR 60861

Fixes incoming breakage for unlanded rust-lang/rust#60861.

Tests are passing locally; the Rust PR now needs to land first.

@Manishearth also says we'll want to split out to a collapsible_if_let once we have let-chains working in Rust nightly or something.

@ghost ghost mentioned this pull request

Jun 27, 2019

@lf- lf- mentioned this pull request

Apr 20, 2021

JohnTitor added a commit to JohnTitor/rust that referenced this pull request

Jul 17, 2022

@JohnTitor

…shtriplett

Stabilize let_chains in Rust 1.64

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: rust-lang#53667 Version: 1.64 (beta => 2022-08-11, stable => 2022-10-22).

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

History

From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled.

Divergent non-terminal matchers

More specifically, rust-lang#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 rust-lang#80357 and rust-lang#88572. As a result, no bugs were found since the integration of rust-lang#88642.

Possible future work

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

Fixes rust-lang#53667

workingjubilee pushed a commit to tcdi/postgrestd that referenced this pull request

Sep 15, 2022

@JohnTitor

Stabilize let_chains in Rust 1.64

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.64 (beta => 2022-08-11, stable => 2022-10-22).

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

History

From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled.

Divergent non-terminal matchers

More specifically, rust-lang/rust#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 rust-lang/rust#80357 and rust-lang/rust#88572. As a result, no bugs were found since the integration of rust-lang/rust#88642.

Possible future work

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

Fixes #53667