Does it upset anyone else when a language lets you do the same thing in multiple syntax ways and there's really no good reason for it

Like I can do

If let Some(_) = x {
//Do a thing
)

Or

If x.is_some() {
//Do a thing
}

You could argue the second is more readable but the first is how you would expect it to be written and what your eyes would be scanning for. So why does it even exist?

I would totally prefer number 2, the closer to English the code is the better

i don't mind, in fact, i prefer having options (pun somewhat intended).

The reason behind it is, that reading the resulting code can be adapted to whatever the context is. Remember that writing readable code is about showing _intent_ to humans and if you specifically say, you don't want the content of the Some variant, because you really only need to know if it is Some at all, then is_some() shows the intent more clear, than if let Some(*ignored*) = ...

Of course at the end of the day, both are identical to the Compiler, since is_some() is implemented via a matches!() macro.

It's always good to have a choice. That being said, anyone who uses nested ternary operators in place of a perfectly good if/else needs to be publicly birched.

@thebiochemic the perfect answer

@jestdotty I’m a big ternary guy myself

@jestdotty you don’t need ternary if you have if expressions.

Full disclosure: I don’t know if Rust has if expressions but I would be disappointed if it hadn’t.

@jestdotty expressions evaluate to a value. So you can do this:

var result = if(condition) { 5 } else { 7 }

Instead of the classic statement style:

var result: Int
if(condition) {
result = 5
} else {
result = 7
}

This is particularly useful for switches.
Kotlin had if and switch expressions from the beginning. Swift added them recently.

@Lensflare i agree 100%

you don't need ternaries, if you can literally use expressions as operands in your stuff.

if {} else {} is what you would use a ternary for by default.
you can do stuff like:
let myvalue = if ... {this} else {that};

basically you can do the same shit with it like terniaries:

let myvalue = (if ... {this} else {that}).do_stuff();
let myvalue = do_other_stuff(if ... {this} else {that});

but also this:

let myvalue = if ... {this} else {return};

and it will be still valid, because it either returns it's inner value, or ends the function.

A related symbol specifically for Options and Results in this context is the ? operator.

@jestdotty terniary is technically also just an if statement with a less clear intent, or am i wrong?

https://dev.to/chinesehuazhou/...

Recommend reading it.

Most languages who allow insane ways of doing the same task in different ways are usually... Poorly designed.

Or like in C++ for example getting too fragmented.

Lack of alternatives must not be bad, it can be quite the opposite a sign that the language authors tried to prevent ambiguity.

Then there are languages like Java where the lack of a real standard lib leads to NIH / Not invented here.

;) Too many ways to do it cause it isn't provided at all by a standard library and needs to be done by a 3rd API library / handrolled.

@jestdotty it's honestly a great book ^^

valid. I find that if .is_some() predates "if let" then "if let" shouldn't exist at all

@kobenz the thing that if let separates from is_some() is that you can combine multiple matches with eachother.

For example you have an Option with an enum inside then you can just unpack it with one singular expression, which is

if let Some(MyEnum::MyVariant(data)) = input {data.do_shit()}

but arguably at this point the readability might become a problem, when you take this too far.

I know what it does and use it pervasively, don't mansplain me @thebiochemic, it's unbecoming