Rust 1.33.0 pre-release testing

[pietroalbini]

The 1.33.0 pre-release is ready for testing. It’s scheduled to be released on Thursday 28th. Release notes can be found here: https://github.com/rust-lang/rust/blob/stable/RELEASES.md.

You can try it out locally with:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

The index is https://dev-static.rust-lang.org/dist/2019-02-25/index.html.

[dhm]

Nice!

@Release notes

• You can now have irrefutable if let and while let patterns. Using this feature will by default produce a warning as this behaviour can be unintuitive. E.g. if let _ = 5 {}

An interesting use case for this is, regarding the lifetimes of unbounded expressions, rewriting the (in)famous

match expr {
    x => {
        // ...
    }
}

as

if let x = expr {
    // ...
}

Right?

Can the expression evaluate to something else than () when it is irrefutable or would we have to add else { unreachable!() } for that to be possible?

[Nemo157]

@dhm looks like it needs the unreachable: playground.

[dhm]

Yep

and no unreachable code lint: playground

[scottmcm]

@dhm

and no unreachable code lint

That might be fine -- I don't think the code needs to emit both an irrefutable pattern lint and an unreachable code lint.

And it's consistent with if true, which also doesn't emit an unreachable code lint for its else block.

[dhm]

@scottmcm

That might be fine – I don’t think the code needs to emit both an irrefutable pattern lint and an unreachable code lint.

I find the unreachable_statement to be a more informative lint (than irrefutable_pattern), and which would only appear if the if let construction were misused.

I've always had the following rule of mind:

if let $pattern = $expression $then_block $( else $else_block )?

// is equivalent to:

match $expression {
    $pattern => $then_block,
    _ => ($( $else_block )?),
}

which works for refutable patterns. But when the if let construction is used with an irrefutable pattern, the above replacement does not apply, and instead unsugars to:

match $expression {
    $irrefutable_pattern => $then_block,
}

i.e. the whole else $else_block does not make any sense here; compiler-wise it could be seen as:

match $expression {
    $irrefutable_pattern => $then_block,
    $( _ => $else_block, )?
}

Thus triggering an unreachable_pattern lint.

TL,DR: it should either trigger unreachable_code or unreachable_pattern (I prefer the latter, given the weird if true { ... } else { ... }-not-triggering-unreachable_code-lint current situation)

[andjo403]

is the example #[cfg(target_vendor="linux")] strange or is it I that do not understand? according to this target vendor possible values is:

• "apple"
• "pc"
• "unknown"

[jethrogb]

@andjo403 I brought this up on GitHub as well, the response was “PRs welcome”

[vorner]

I don’t know if this is the right place, as this probably is not directly related to this specific release, but the new features made me try this bit of code, which doesn’t compile (and requires the quite useless if which will produce the warning instead). Is that expected? Shouldn’t let also accept a pattern, same as if let?

enum Creature {
    Crab(String),
    Lobster(String),
    Person(String),
}

fn main() {
    let state = Creature::Crab("Ferris".to_string());

    let Creature::Crab(name) | Creature::Person(name) | Creature::Lobster(name) = state;
}

[Centril]

@vorner

Shouldn’t let also accept a pattern, same as if let ?

That the plan, however, this was more complicated to implement so it was postponed for later. Further work is tracked in Tracking issue for RFC 2535, 2530, 2175, "Or patterns, i.e `Foo(Bar(x) | Baz(x))`" · Issue #54883 · rust-lang/rust · GitHub.