Rust Project Goals

I posted this blog post that proposes that we ought to name the trait Handle and define it as a trait where clone produces an "entangled" value -- i.e., a second handle to the same underlying value.

Before that, there's been a LOT of conversation that hasn't made its way onto this tracking issue. Trying to fix that! Here is a brief summary, in any case:

• It began with the first Rust Project Goals program in 2024H2, where Jonathan Kelley from Dioxus wrote a thoughtful blog post about a path to high-level Rust that eventually became a 2024H2 project goal towards ergonomic ref-counting.
• I wrote a series of blog posts about a trait I called Claim.
• Josh Triplett and I talked and Josh Triplett opened RFC #3680[], which proposed a use keyword and use || closures. Reception, I would say, was mixed; yes, this is tackling a real problem, but there were lots of concerns on the approach. I summarized the key points here.
• Santiago Pastorino implemented experimental support for (a variant of) RFC #3680[] as part of the 2025H1 project goal.
• I authored a 2025H2 project goal proposing that we create an alternative RFC focused on higher-level use-cases which prompted Josh Triplett and I have to have a long and fruitful conversation in which he convinced me that this was not the right approach.
• We had a lang-team design meeting on 2025-08-27 in which I presented this survey and summary of the work done thus far.
• And then at the RustConf 2025 Unconf we had a big group discussion on the topic that I found very fruitful, as well as various follow-up conversations with smaller groups. The name Handle arose from this and I plan to be posting further thoughts as a result.

RFC #3680: https://github.com/rust-lang/rfcs/pull/3680

I wrote up a brief summary of my current thoughts on Zulip; I plan to move this content into a series of blog posts, but I figured it was worth laying it out here too for those watching this space:

09:11 (1) I don't think clones/handles are categorically different when it comes to how much you want to see them made explicit; some applications want them both to be explicit, some want them automatic, some will want a mix -- and possibly other kinds of categorizations.

09:11 (2) But I do think that if you are making everything explicit, it's useful to see the difference between a general purpose clone and a handle.

09:12 (3) I also think there are many classes of software where there is value in having everything explicit -- and that those classes are often the ones most in Rust's "sweet spot". So we should make sure that it's possible to have everything be explicit ergonomically.

09:12 (4) This does not imply that we can't make automatic clones/handles possible too -- it is just that we should treat both use cases (explicit and automatic) as first-class in importance.

09:13 (5) Right now I'm focused on the explicit case. I think this is what the use-use-everywhere was about, though I prefer a different proposal now -- basically just making handle and clone methods understood and specially handled by the compiler for optimization and desugaring purposes. There are pros and cons to that, obviously, and that's what I plan to write-up in more detail.

09:14 (6) On a related note, I think we also need explicit closure captures, which is a whole interesting design space. I don't personally find it "sufficient" for the "fully explicit" case but I could understand why others might think it is, and it's probably a good step to take.

09:15 (7) I go back and forth on profiles -- basically a fancy name for lint-groups based on application domain -- and whether I think we should go that direction, but I think that if we were going to go automatic, that's the way I would do it: i.e., the compiler will automatically insert calls to clone and handle, but it will lint when it does so; the lint can by deny-by-default at first but applications could opt into allow for either or both.

I previously wanted allow-by-default but I've decided this is a silly hill to die on, and it's probably better to move in smaller increments.

I've updated the top-level description to show everything we're tracking here (please let me know if anything's missing or incorrect!).

• [merged] Sanitizers target modificators / https://github.com/rust-lang/rust/pull/138736
• [merged] Add assembly test for -Zreg-struct-return option / https://github.com/rust-lang/rust/pull/145382
• [merged] CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits / https://github.com/rust-lang/rust/pull/146368
• -Zharden-sls / https://github.com/rust-lang/rust/pull/136597
  • Waiting on review
• #![register_tool] / https://github.com/rust-lang/rust/issues/66079
  • Waiting on https://github.com/rust-lang/rfcs/pull/3808
• -Zno-jump-tables / https://github.com/rust-lang/rust/pull/145974
  • Active FCP, waiting on 2 check boxes

I've updated the top-level description to show everything we're tracking here (please let me know if anything's missing or incorrect!).

Deref/Receiver

• Ding Xiang Fei keeps updating the PR: https://github.com/rust-lang/rust/pull/146095
• They're also working on a document to explain the consequences of this split

Arbitrary Self Types

• https://github.com/rust-lang/rust/issues/44874
• Waiting on the Deref/Receiver work, no updates

derive(CoercePointee)

• https://github.com/rust-lang/rust/pull/133820
• Waiting on Arbitrary self types

Pass pointers to const in asm! blocks

• RFC: https://github.com/rust-lang/rfcs/pull/3848
• The Lang team went through the RFC with Alice Ryhl on 2025-10-08 and it's in FCP now

Field projections

• Benno Lossin opened a PR here: https://github.com/rust-lang/rust/pull/146307
• Being reviewed by the compiler folks

Providing \0 terminated file names with #[track_caller]

• The feature has been implemented and stabilized with file_as_c_str as the method name: https://github.com/rust-lang/rust/pull/145664

Supertrait auto impl RFC

• Ding Xiang Fei opened the RFC and works with the reviewers: https://github.com/rust-lang/rfcs/pull/3851

Other

• Miguel Ojeda spoke to Linus about rustfmt and they came to agreement.

Cargo tracking issue: https://github.com/rust-lang/cargo/issues/15844. The first implementation was https://github.com/rust-lang/cargo/pull/15845 in August that added build.analysis.enabled = true to unconditionally generate timing HTML. Further implementations tasks is listed in https://github.com/rust-lang/cargo/issues/15844#issuecomment-3192779748.

Haven't yet got any progress in September.

Status update October 6, 2025

The build-dir was split out of target-dir as part of https://github.com/rust-lang/cargo/issues/14125 and scheduled for stabilization in Rust 1.91.0. 🎉

Before re-organizing the build-dir layout we wanted to improve the existing layout tests to make sure we do not make any unexpected changes. This testing harness improvement was merged in https://github.com/rust-lang/cargo/pull/15874.

The initial build-dir layout reorganization PR has been posted https://github.com/rust-lang/cargo/pull/15947 and discussion/reviews are under way.