error[E0658]: `let` expressions in this position are unstable

Unsupported:
if let Ok(src) = stream.peer_addr() && let Ok(dst) = stream.local_addr() { ... }

Supported:
if let (Ok(src), Ok(dst)) = (stream.peer_addr(), stream.local_addr()) { ... }

Okay then, rustc. Whatever makes you happy.

@G33KatWork Rust is not my primary development language, so please feel free to correct my possibly wrong assumptions here.

But I feel that this pattern of `if let .. && if let ..` looks really weird. It could mislead someone into believing they could also use other logical operations, such as `||`.

@greg In my mind || doesn't make sense at all for if-let-expressions.

Both, `peer_addr()` and `local_addr()` need to return some address that I want to use inside of the if body. One isn't enough because the destructuring requires binding `src` and `dst` to the inner values of the `Option`s returned by both functions. If one doesn't return `Some`, the pattern matching fails, so peer_addr AND local_addr needs to return Some.

But yeah, && might be a bad keyword, because nothing else makes sense.

@G33KatWork is that on the latest rust version? They added some new features around that guy IIRC

@dmnk 1.89 nightly 🤷‍♂️
Maybe I'm holding it wrong.

@G33KatWork That's exactly what I'm trying to say, yes.

Then again, the naming of `if let` might not be ideal.. But it's always easy to criticize other programming languages ;)

@greg @G33KatWork The whole `if-let` thing was mistake from the get-go. And now it keeps sprouting extension proposals because people discover the gaps and issues and try to fill them.

`is` offered an alternative that was superior in many aspects, but Rust's way of doubling down on bad decisions means we'll never see that in Rust.

@soc @G33KatWork on the upside, Rust is at least not using product types for error handling ;)

@greg @G33KatWork Yeah, that would be pretty stupid.

@soc @G33KatWork Looking at you, Golang ;)

@greg @G33KatWork if-let is a prime example of how Clever often beats Readable in Rust Land IMO

(I just wrestled with some code that swear to God was optimized for the minimal number of semicolons...)

@greg @G33KatWork
I could see

if let Ok(x) = foo || let Ok(x) = bar { ... }

make sense, though... x would simply get the value from the first expression that matches.

But next thing someone is going to ask for supporting code like

if let Ok(x) = foo && (let Ok(y) = bar || let Ok(y) = baz) { ... }

and things would get more complicated

@oots @G33KatWork yes, but then you'd be limited to using the same type (or even the same variable binding) for the `||` operator, whereas `&&` would allow for different types (and variables). That's not exactly pretty either. Also, you wouldn't learn about which part of the `||` was satisfied.

I guess in that case, the user could just write `if let Ok(x) = foo.or(bar)`, right?

@G33KatWork Sounds modern enough, probably just the way it is

@greg @G33KatWork
Yes, with `||` it would have to be the same type. And TIL about `Result.or`.