In this case this is a Rust bug that will be fixed in the next edition: https://github.com/rust-lang/rust/issues/124085
There's value to being opinionated about API design, but there's also cost. And Rust is supposed to be playing in the same sandbox as the lower level tools.
I don’t think either of those is true. Encoding the ownership in the type system makes things clearer, imposes a compile-time cost but not run-time cost. Also, there isn’t any magic in the stdlib implementation of Mutex and Rwlock other than implementing it natively for every OS. This means that it is possible to implement the pattern for the examples you gave.
Idiomatically, you would then make `Foo::new_unchecked()` unsafe, with the precondition that nobody else is accessing the same external resource, and that `Foo::new_unchecked()` is only ever called once.
So long as MacGuffin doesn't have any data in it, it essentially evaporates at runtime. This is a zero size type (ZST) so we can store that in no bytes of RAM, we can use no registers at all to pass it into a function, and so on. If you're a C programmer this doesn't make sense because you don't have ZSTs, all your types take up at least one byte, but Rust isn't like that.
If locking and unlocking semantics are a good fit for whatever you are doing, then you can just do a lock implementation setting whatever memory mapped registers you need. There is no constraint here whatsoever.
Nobody is advocating for separate atomics in every little object in Rust. That's a Java idea that failed miserably long before Rust was even around.
actually it's a common pattern in complicated multi threaded code or similar to require that
technically yes but practically this is nearly always programmer bug to bypass a lock
If you port C code to rust and now need much more locks in Rust it's nearly always an indicator for either your C code not having been correct (e.g. accessing resources behind a lock without acquiring it) and/or you having badly structured code.
There is basically hardly ever a need to use unsafe for such cases as long as you don't write your own fundamental data structures (e.g. specific kinds of idk. lock free concurrent data structures).
Honestly the main reason I see unnecessary unsafe code usage is people trying to write C or C++ code in rust instead of writing rust in rust.
you can rely on implicit drop to always make sure you never forget to unlock (as long as you don't leak the guard which is hard to do but possible)
but you can also explicitly drop it to have full control over when exactly it will unlock
and in neither situation you have to worry about accidentally bypassing it
and in complicated code relying implicitly on a mutex or similar to still be kept it's a common pattern to do so (i.e. to explicitly drop the mutex guard even if not needed to be extra clear about for how long exactly the lock is held)
Sugary syntax is always an issue when side effects matter.
Having said that, I adore procedural code in general, but it does make ownership a fun mental exercise.
Ultimately this isn't really a problem with how Rust's Mutex/RwLock/etc. works, it's just a poor choice with how the lifetime of the lock guard is figured in the 'if let' case. This poor choice will be fixed in the 2024 Rust edition, and this problem will go away.
The main point being: the implicitness is not necessary for "compiler makes sure you don't forget". So the original comment about how usage of the explicitly named and paired APIs can clarify intent both for the writer and reader can still stand while not implying that forgetting is involved. I see this dichotomy often being drawn and I think it's important to consider the language design space more granularly. I think a reminder is a better fix for forgetting, rather than assuming what you wanted and doing it for you.
(the explicit calls also let you / work better with "go to defintion" on the editor to see their code, learn what to look up in a manual, step in with a debugger, see reasonable function names in stack traces and profiles, pass / require more arguments to the drop call, let the drop call have return / error values you can do something about (consider `fclose`), let the drop call be async, ...)
Plus you're working in a memory unsafe, concurrency unsafe language.
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
`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.
Looks like this is getting fixed in Rust 2024 :)
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.
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?
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).