undefined | Better HN

0 pointsjosephg1y ago0 comments

Yeah, but I almost always want to pattern match out the value when I do that.

As I said in the post you can also write this:

    if let (Some(x), true) = (my_option, expr) {

But then it doesn't short-circuit. (expr is evaluated in all cases, even when the optional is None).

Both approaches are also weird. It'd be much better to just fix the language to make the obvious thing work.

0 comments

lifthrasiir1y ago

I personally use two conditionals for such case. Yes, I might have written Rust too long to say this but it is more like a minor ergonomic fix and any solution should be generalizable into other use cases. The eventually accepted syntax, `if let PAT = EXPR {&& EXPR}` [1], is okay by itself but not (yet) generalized and that's my current complaint about it. The whole `{let PAT = EXPR &&} EXPR` should have been a valid expression in my opinion. (This exact suggestion is not in the RFC, the closest would be making `let PAT = EXPR` a boolean expression which really looks like a mistake.) Maybe I should check whether this was ever suggested...

[1] https://rust-lang.github.io/rfcs/2497-if-let-chains.html

josephgOP1y ago

> I personally use two conditionals for such case.

Me too. But that often makes my logic worse. Its quite common to want to share the same code in the else branch, for example:

    if let Some(val) = opt {
        if expr {
            // ....
        } else {
            do_complex_stuff();
        }
    } else {
        do_complex_stuff();
    }

I don't want to copy+paste that complex code in two places. And you can fix that in turn with a named block & named break statements or a function - but .... whyyyyy? Why is this even a thing? The solution is so obvious. The RFC you linked to fix it is fine, and 6 years old now. My sister has a child in grade school who was born after that RFC was drafted.

Yes, you can work around this hole in the language any number of ways with ugly code. But I don't want to do that. I want to use a good language.

lifthrasiir1y ago

I'm worried that you want a "good" language at any circumstance, which is not even generally possible but also at odds with other aspects of languages. This still counts as minor for me because it is just slightly annoying and doesn't make something impossible or much harder to read (and the readability varies enough that this threshold is much higher than this case).

1 more reply

j / k navigate · click thread line to collapse

0 pointsjosephg1y ago0 comments

Yeah, but I almost always want to pattern match out the value when I do that.

As I said in the post you can also write this:

    if let (Some(x), true) = (my_option, expr) {

But then it doesn't short-circuit. (expr is evaluated in all cases, even when the optional is None).

Both approaches are also weird. It'd be much better to just fix the language to make the obvious thing work.

0 comments

lifthrasiir1y ago

[1] https://rust-lang.github.io/rfcs/2497-if-let-chains.html

josephgOP1y ago

> I personally use two conditionals for such case.

Me too. But that often makes my logic worse. Its quite common to want to share the same code in the else branch, for example:

    if let Some(val) = opt {
        if expr {
            // ....
        } else {
            do_complex_stuff();
        }
    } else {
        do_complex_stuff();
    }

Yes, you can work around this hole in the language any number of ways with ugly code. But I don't want to do that. I want to use a good language.

lifthrasiir1y ago

1 more reply

j / k navigate · click thread line to collapse