Stabilize the let chain!

Man, what a pain in neck without the let chain. Today I run into a situation that I want to deal with the packets of TCP/UDP only

let Some(tcp) = proto else {
      let Some(udp) = proto else {
          return early; }
//the compiler complains that  it needs something here. WTF!

damn this won't work. :slight_smile: We won't have this problem if let chain got stabilized.

At this level of highly-abstracted pseudo-code itโ€™s impossible to tell what your code is actually supposed to do, without more information. E.g. consider adding / comparing against a โ€œfixedโ€ version that uses let-chains; perhaps for contrast also add a fixed (possible more tedious) version using stable rust features.

Because all Iโ€™m seeing here is code that cannot possibly compile because it contains a let-else statement (i.e. the outer one of the two) with a non-diverging else branch, and an angry-looking comment complaining about the fact that the compiler would rightfully disallow such code.


You are right, I forgot let else has to diverge.:slight_smile:

The tracking issue contains more info on the state:

For short: while no current implementation bugs are known (I think), there were a lot of bugs with this feature before. We need more tests to confirm that it is really ready to be shipped.


I actually want to do the following, seems hard to do: if proto is tcp or proto is udp do the work, or else, exist seems very hard to do a "or" between two "let x = "

You can use a | pattern to pull out information from either of several patterns if it has the same shape in both arms. For example, it's possible to extract either A.0 or B.0 in one let statement here since they're both u32:

pub enum Foo {

fn main() {
    let x: Foo = Foo::B(42);
    let (Foo::A(i) | Foo::B(i)) = x else {


What's wrong with

match proto {
   Tcp(...) => doit_tcp(),
   Udp(...) => doit_udp(),
   _ => { return early }



This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.