3 ms·

> Rust doesn't have syntax to mark a struct field as being in a borrowed state. > ast_nodes: Vec<&'Self::source str>, Oh, that would be neat to replace the h

> Rust doesn't have syntax to mark a struct field as being in a borrowed state. > ast_nodes: Vec<&'Self::source str>, Oh, that would be neat to replace the https://github.com/tommie/incrstruct https://github.com/tommie/incrstruct I wrote for two-phase initialization. Unlike Ouroboros and self_cell, it uses traits so the self-references can be recreated after a move. Whether it's a good idea, I don't know, but the magic Ouroboros applies to my struct feels wrong. But I say that as someone coming from C++. > if let Some(x) = some_var && some_expr { } Coming from Go, I was surprised that something like if let Some(x) = some_var; expr(x) { } isn't a thing.

lifthrasiir 2y ago
`if some_var.is_some_and(|x| some_expr)` is the current way to do that. It is less flexible and doesn't actually bind `x` into the conditional body (hence the proposal) but works today.
- josephg 2y ago
  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.
  - lifthrasiir 2y 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 https://rust-lang.github.io/rfcs/2497-if-let-chains.html
    - josephg 2y 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.
      - lifthrasiir 2y 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).
        josephg 2y 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. Yes, I do want a good programming language. I agree its relatively minor compared to the other issues I talked about in the blog post. In what way is this at odds with other aspects of the language? If its at odds with the rest of the language, why is this feature being added? https://rust-lang.github.io/rfcs/2497-if-let-chains.html https://rust-lang.github.io/rfcs/2497-if-let-chains.html
        lifthrasiir 2y ago
        Mainly a long-term consequence in teaching and readability. The RFC was accepted only after considering such trade-offs.
- tommiegannert 2y ago
  Thanks for the suggestion. It does avoid a nested if-statement, so agreed it's useful.
spacechild1 2y ago
> Coming from Go, I was surprised that something like > > if let Some(x) = > some_var; expr(x) { } > > isn't a thing. The same thing in C++17: if (auto x = something(); expr1(x)) {} else if (expr2(x)) {} It's really neat to have the variable scoped to the if/else-clause.

lifthrasiir 2y ago

`if some_var.is_some_and(|x| some_expr)` is the current way to do that. It is less flexible and doesn't actually bind `x` into the conditional body (hence the proposal) but works today.

josephg 2y ago
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.
- lifthrasiir 2y 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 https://rust-lang.github.io/rfcs/2497-if-let-chains.html
  - josephg 2y 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.
    - lifthrasiir 2y 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).
      - josephg 2y 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. Yes, I do want a good programming language. I agree its relatively minor compared to the other issues I talked about in the blog post. In what way is this at odds with other aspects of the language? If its at odds with the rest of the language, why is this feature being added? https://rust-lang.github.io/rfcs/2497-if-let-chains.html https://rust-lang.github.io/rfcs/2497-if-let-chains.html
        lifthrasiir 2y ago
        Mainly a long-term consequence in teaching and readability. The RFC was accepted only after considering such trade-offs.
tommiegannert 2y ago
Thanks for the suggestion. It does avoid a nested if-statement, so agreed it's useful.

spacechild1 2y ago

> Coming from Go, I was surprised that something like > > if let Some(x) = > some_var; expr(x) { } > > isn't a thing. The same thing in C++17: if (auto x = something(); expr1(x)) {} else if (expr2(x)) {} It's really neat to have the variable scoped to the if/else-clause.