While this is very informational and everything, it is very hard to follow in the manner it is supposed to be. Sometimes it's too succinct, sometimes I can't understand a word or phrase because of the uneven pace of pronunciation like @ 9:17 (yeah, and the accent too).
So I've wondered about this syntax more generally. A more typical use of "if let" would be something like "if let Some(new_variable) = my_option". Notice we are attempting to instantiate new_variable with the value inside my_option, so I think that may be why it's on the left side, so it resembles "let new_variable = a_value", although to me "if let my_option = Some(new_variable)" is just as readable provided you focus on the "if" and not the "let" xD if let is really designed for this instantiation unwrapping use case, which is where the let part comes from. For an enum variant without an associated value like the List::Empty in question, this meaning gets lost, which I think is why he chooses to even write an is_empty() method. Now you can write "if list.is_empty()" answering the simple question "is the list empty?" instead of "if let List::Empty = *list" answering the question "Is the list of the empty variant which has no associated value?" The statement "if *list == List::Empty" is a bit like saying "if my_num == u32". You're really trying to do a type check (or more accurately a variant check) rather than an equality check. It would be nice if enums came with a built in convenience method for this. Option has .is_some() and .is_none() and Result has .is_ok() and .is_err(), which do exactly what you are attempting to do, check the variant without bothering with the associated value. Maybe some smart person somewhere will write a derive macro for these sort of methods on enums. ^^^ I have no authority to say these things but I hope they help
👍👍 Rust by example is a great book and reference too. Thanks for all the hard work on it.
Once you have read the book... This is a good summary overview.
Good talk! I liked that the presenter jumped right in, although it might have been hard to follow for someone completely unfamiliar with Rust.
🙏 thank you
While this is very informational and everything, it is very hard to follow in the manner it is supposed to be. Sometimes it's too succinct, sometimes I can't understand a word or phrase because of the uneven pace of pronunciation like @ 9:17 (yeah, and the accent too).
@12:10 why isn't _if let List::Empty = *list {...}_ equivalent to _if *list == List::Empty {...}_?
So I've wondered about this syntax more generally. A more typical use of "if let" would be something like "if let Some(new_variable) = my_option". Notice we are attempting to instantiate new_variable with the value inside my_option, so I think that may be why it's on the left side, so it resembles "let new_variable = a_value", although to me "if let my_option = Some(new_variable)" is just as readable provided you focus on the "if" and not the "let" xD if let is really designed for this instantiation unwrapping use case, which is where the let part comes from. For an enum variant without an associated value like the List::Empty in question, this meaning gets lost, which I think is why he chooses to even write an is_empty() method. Now you can write "if list.is_empty()" answering the simple question "is the list empty?" instead of "if let List::Empty = *list" answering the question "Is the list of the empty variant which has no associated value?"
The statement "if *list == List::Empty" is a bit like saying "if my_num == u32". You're really trying to do a type check (or more accurately a variant check) rather than an equality check. It would be nice if enums came with a built in convenience method for this. Option has .is_some() and .is_none() and Result has .is_ok() and .is_err(), which do exactly what you are attempting to do, check the variant without bothering with the associated value. Maybe some smart person somewhere will write a derive macro for these sort of methods on enums.
^^^ I have no authority to say these things but I hope they help