Not the best example in "6.3 Concise Control Flow with if let".

[andywwright]

Hey guys!

First of all - thank you very much for the great language and the great book. I'm new to coding, so I'm sorry if anything (or everything) I say is stupid.

At least for me, there is a very bad example in the "6.3 Concise Control Flow with if let" chapter. It says:

if let Some(3) = some_u8_value {
    println!("three");
}

I had been somewhat at a loss as to why or how this expression is any better than say

if Some(3) == some_u8_value {
    println!("three");
}

and it took me some time to come to the conclusion that in this particular case it probably isn't better at all, if not worse for arguably "weird" (for me in that state of mind) syntax. By weird, I mean that at the time the part after "if" looked like

let 3 = x

for me, which had just turned my head around :)

Long story short, I think it is more clear to explain "if let" through use of unwrapping the optional value (if it is there), like so:

if let Some(x) = some_u8_value {
    println!("The unwrapped value is {}", x);
}

I hope that makes sense.

[steveklabnik]

It does, thanks! you're right that being able to use the binding is the key feature of if let in this context. I'll give it some consideration. Thank you!

[Centril]

My personal inclination is that if let Some(3) = ... { .. } is idiomatic because with Some(3) == ... you are actually creating such a value in memory while with let Some(3) this is just decomposable pattern matching where Some(3) doesn't need to be in memory. While the optimizer will optimize both to the same instructions, == has to go through a detour via the PartialEq trait and so it is a more complicated approach. Using if let Some(3) also shows the power of pattern matching I think.

[andywwright]

In my humble opinion, we are talking about a book for a newbie here. And we have just told them that "let is used to introduce a binding, to bind some value to a name, so it can be used later".

The thing is, in case of if let Some(3) = ... { .. } this particular let binds nothing and because of that, entirely new (for a newbie) if let syntax could look absurd at the moment.

[imbolc]

I got if let syntax only in chapter 18 :) Also for me introducing if let in early chapters seems not only confusing but also redundant, as all the examples can probably be rewritten with only match without any drawbacks. Why do we need it there at all?

[hoijui]

I am a rust newbie too (Java coder). I love the book, and start to be very excited about the language, and while at times some things are explained maybe a bit to verbosely for me, I would not change that at all... I consider it very good, thank you!
but in this part about if let, I felt totally lost:

• Wasn't there a normal if already earlier in the book?
• Or do I remember wrong, and if so, why would the language use if let instead of just if?
• If they both exist, what is the difference?
• As there is let in it, which variable is getting assigned here?
  ...

So I give a +1 to @andy-rust and @imbolc here.

[andywwright]

You'd better think about if let as a one-handed match with no exhaustive checking enforced. In the case of the given example, it has nothing to do with if or let, that's why it is so confusing :)

Maybe it would be better to rename the whole operator, call it match once or something like that.

[hoijui]

hmm... thanks @andy-rust !
I wish something like this description would be in the book, but that almost sounds like criticism on the language... ;-)
I guess I will rather use the match + _ approach then. I don't know if there might be an even better name, but I would use it if it was called match once.

[L0uisc]

@andywswan what would happen to cases where I want to do if let ... { ... } else { ... } if the name changes to match once? Will the else still work? I realise that the expression can be written as match ... { interesting_case => ..., everything_else => ..., }, but still...

[andywwright]

@L0uisc sure "else" should work as usual. But it doesn't matter, because everyone seems to be happy with "if let" as it is.

[L0uisc]

I am reading the book for the first time and have only advanced to Chapter 10. When I first read about if let, it confused me too. I then stopped and analyzed every part of the "match" which is "equivalent" to if let according to the book. I think one small change would solve the problem for me: include the binding of the some_u8_value in the if let version as well. Maybe, if you believe that is not enough, we can insert an explanation detailing for each part of the if let expression which part of the match expression is its equivalent. (Some places I used "expression" should maybe be "statement." I am not sure which is each of the constructs I am referring to.)

[andywwright]

No amount of explanations would be enough for me because of the fact, that in the case of if let Some(3) = ... { .. } this let binds no variables. Furthermore, it visibly makes an assignment to a solid type! (U8 or whatever 3 is there after unwrapping the Option). There is no reasonable explanation for this use case to a newbie or to anyone for that matter using just let. And though it can be easily explained with match once and I have successfully done that multiple times with my friends, we can't just put it in The book, can we?

The only right way of proceeding would be to open an RFC with a proposal of replacing this vague if let thing with clear match once or whatever better wording, but I simply do not think there is enough demand to bother the entire society with changing the semantics of The language.

[L0uisc]

I think the if is actually not meaning something else here than in other places. The block is executed if the pattern matches and skipped if not. The fact that the let here is not a binding, but syntax for matching a pattern, should be made clearer.

Just FYI: there is while let too, which executes its block while the pattern matches. So I think the best would be to make it clear that the let in if let and while let isn't a binding.