goals

Interesting, thanks for the links! I'm curious as to how many of the apparent issues are attributable to lifetime extension specifically as opposed to something else like async-related deadlocks as mentioned in the parent to the first linked comment (which I feel I've heard much more about), especially after the Rust 2024 changes. That being said, after a bit more searching I found this 2023 blog from one of the Rust devs [0] which supports the "widespread" description at the time: > One very common problem is deadlocks (or panics, for ref-cell) when mutex locks occur in a match scrutinee so I think we can chalk this up to me being insufficiently well-read. I think it would be interesting to see to what extent the Rust 2024 changes alleviated the problem since it only changed if let, but I haven't found that information (yet). There's als

I think this one might be at greater risk than usual of being dropped, because it's explicitly mutually exclusive with another accepted project goal (pin ergonomics): https://github.com/rust-lang/rust-project-goals/blob/main/sr...

> # How does this relate to the "pin ergonomics" initiative? > This work is an alternative to Project Goal 2025H2: Continue Experimentation with Pin Ergonomics, which includes the following extensions: > A new item family pin in lvalues, e.g. &pin x, &pin mut x, &pin const x. > A one-off overload of Rust's Drop trait, e.g. fn drop(&pin mut self). > A new item kind pin in patterns, e.g. &pin <pat>. > Notably, this work does not solve pin's duplicate definition problem, meaning that even with these extentions we still end up with Trait and PinnedTrait variants of existing traits. The Drop trait being the exception to this, since the initiative is proposing to special-case it using a one-off overload. https://github.com/rust-lang/rust-project-goals/blob/main/sr...

I think it could be different timelines. The Google projects interested in better C++ interop have been around for 2 decades - Chromium and Android. They’ll be ok if the effort bears fruit in a year or two. The latest on this project is in this update - https://github.com/rust-lang/rust-project-goals/issues/388. They’re working on it, but no progress yet. I think the author wanted something now, which is a completely acceptable reason to start his own project.

You have an inevitable overhead of managing the owned buffer when compared against simply passing mutable borrow to an already existing buffer. Imagine if `io::Read` APIs were constructed as `fn read(&mut self, buf: Vec<u8>) -> io::Resul<Vec<u8>>`. Parity with synchronous programming is an explicit goal of Rust async declared many times (e.g. see here https://github.com/rust-lang/rust-project-goals/issues/105). I agree with your rant about the illusion of synchronicity, but it does not matter. The synchronous abstraction is immensely useful in practice and less leaky it is, the better.

> IRC the plan isn't to use Polonius instead of NLL, but rather use NLL and kick off Polonius for certain failure cases. Indeed. Based on the last comment on the tracking issue [0], it looks like they have not figured out whether they will be able to optimize Polonius enough before stabilization, or if they will try non-lexical lifetimes first. [0]: https://github.com/rust-lang/rust-project-goals/issues/118