4 ms·

I see it as a consequence of Rust being too liberal with additions to the language. It's hard to maintain some of these guarantees in the presence of certain s

I see it as a consequence of Rust being too liberal with additions to the language. It's hard to maintain some of these guarantees in the presence of certain syntactic forms. This happens in all languages. It is a little hilarious to see a rustaceon write: > and you can sus out if a program is going to cause a deadlock by just making sure you aren't acquiring multiple simultaneous locks. Ah.. not a problem! You just have to not ever have the problem. Then, of course at the opposite end of the article: > I wrote this block because this has specifically bitten different Rust crates in the wasmCloud project multiple times :D

deleted 2y ago
[deleted]
dathinab 2y ago
The issue here isn't new features at all. `if let` is more or less syntax sugar for `match`. And match behaves like that, too and has been in rust since 1.0. That match did behaves like that is due to some old, you could say legacy, reasons and had been criticized even in the early rust 1.x days. But changing a behavior which subtle change when locks are released is not something you can easily fix with a rust edition so we are pretty much stuck with it.
- Philpax 2y ago
  Funny you say that: https://github.com/rust-lang/rust/issues/131154 https://github.com/rust-lang/rust/issues/131154 Looks like this is getting fixed in Rust 2024 :)
  - dathinab 2y ago
    I haven't been supper up to date with changes to rust-lang recently (I had seen that they are stabilizing if_let_rescope but didn't look into what it is, to much to do at work). Through making if-let less syntax sugar for changing a implicit behavior people most likely didn't rely on but have problems with seems like a very good idea My comment about this being hard to change was mainly about match. Not considering the option of making if-let less syntax sugary. And in difference to if-let, for match people do (or at least did years ago in production code) rely on it.
- akira2501 2y ago
  > `if let` is more or less syntax sugar for `match`. Which are new features for systems languages that otherwise rely on RAII for locking. So it's in the class of "original sin." > so we are pretty much stuck with it. You could refuse to compile it under some set of flags. Isn't that the basic value premise of the language here?
  - sunshowers 2y ago
    It is true that Rust is the first major language with both pervasive, deterministic RAII and pattern matching. Kind of wild to be honest! A real marriage of systems and functional code.
- dathinab 2y ago
  To elaborate a bit more this is a consequence of a overlapping of two design decisions: 1) temporaries being added "alongside" the item they appear in. This makes a tone of thing much much simpler, but comes back to bites us here. 2) "alongside" for match statement meaning alongside the whole statement (but for `if <cond> {` it's alongside the condition) 3) things being always dropped at the very end of the scope if not moved out from it earlier, which again makes things easier to understand in most cases. both had been discussed a bunch around 1.0/early 1.x days and both are things which in most situations make it easier to write rust code (and for beginners potentially much easier) but both have also drawbacks like the not-that-common example in this blog or e.g. in async where rust has to keep any values which impl Drop around across async await calls as it can't know if there is a side effect in Drop In the past I personally had been a contender of allowing the compiler to drop value anywhere between the last time they have been referenced and the end of the scopes without any rules or stability about where exactly (i.e. if you need a guard to be kept around you need to be explicit about it). But working more together with people of very varying skill levels in the last 5/6 years made me change my mind and agree that that would have been a terrible idea. And having rules about guaranteed drops as early as possible seem initially easy but aren't due to things like conditional moves, partial moves etc. I.e. it would still be quite a bit more complicated to teach it. Furthermore in both alternatives to 3) you likely still wouldn't (guaranteed) drop the guard temporary in the other match branch before you requesting the new guard as guaranteeing compiler behavior like that means having a lot of additional edges in many partial move scenarios and potentially even a bunch of additional branch. In both cases it would likely increase code size and mess with the branch predictor and I-caches and be generally just not good (but it would help with async await boundaries).

deleted 2y ago

[deleted]

dathinab 2y ago

The issue here isn't new features at all. `if let` is more or less syntax sugar for `match`. And match behaves like that, too and has been in rust since 1.0. That match did behaves like that is due to some old, you could say legacy, reasons and had been criticized even in the early rust 1.x days. But changing a behavior which subtle change when locks are released is not something you can easily fix with a rust edition so we are pretty much stuck with it.

Philpax 2y ago
Funny you say that: https://github.com/rust-lang/rust/issues/131154 https://github.com/rust-lang/rust/issues/131154 Looks like this is getting fixed in Rust 2024 :)
- dathinab 2y ago
  I haven't been supper up to date with changes to rust-lang recently (I had seen that they are stabilizing if_let_rescope but didn't look into what it is, to much to do at work). Through making if-let less syntax sugar for changing a implicit behavior people most likely didn't rely on but have problems with seems like a very good idea My comment about this being hard to change was mainly about match. Not considering the option of making if-let less syntax sugary. And in difference to if-let, for match people do (or at least did years ago in production code) rely on it.
akira2501 2y ago
> `if let` is more or less syntax sugar for `match`. Which are new features for systems languages that otherwise rely on RAII for locking. So it's in the class of "original sin." > so we are pretty much stuck with it. You could refuse to compile it under some set of flags. Isn't that the basic value premise of the language here?
- sunshowers 2y ago
  It is true that Rust is the first major language with both pervasive, deterministic RAII and pattern matching. Kind of wild to be honest! A real marriage of systems and functional code.
dathinab 2y ago
To elaborate a bit more this is a consequence of a overlapping of two design decisions: 1) temporaries being added "alongside" the item they appear in. This makes a tone of thing much much simpler, but comes back to bites us here. 2) "alongside" for match statement meaning alongside the whole statement (but for `if <cond> {` it's alongside the condition) 3) things being always dropped at the very end of the scope if not moved out from it earlier, which again makes things easier to understand in most cases. both had been discussed a bunch around 1.0/early 1.x days and both are things which in most situations make it easier to write rust code (and for beginners potentially much easier) but both have also drawbacks like the not-that-common example in this blog or e.g. in async where rust has to keep any values which impl Drop around across async await calls as it can't know if there is a side effect in Drop In the past I personally had been a contender of allowing the compiler to drop value anywhere between the last time they have been referenced and the end of the scopes without any rules or stability about where exactly (i.e. if you need a guard to be kept around you need to be explicit about it). But working more together with people of very varying skill levels in the last 5/6 years made me change my mind and agree that that would have been a terrible idea. And having rules about guaranteed drops as early as possible seem initially easy but aren't due to things like conditional moves, partial moves etc. I.e. it would still be quite a bit more complicated to teach it. Furthermore in both alternatives to 3) you likely still wouldn't (guaranteed) drop the guard temporary in the other match branch before you requesting the new guard as guaranteeing compiler behavior like that means having a lot of additional edges in many partial move scenarios and potentially even a bunch of additional branch. In both cases it would likely increase code size and mess with the branch predictor and I-caches and be generally just not good (but it would help with async await boundaries).