Try   HackMD

T-lang planning meeting agenda

  • Meeting date: 2025-06-04

Attendance

  • People: nikomatsakis, tmandy, TC, Josh, eholk, cramertj, Nadri, Tomas, Yosh, scottmcm, Jubilee

Meeting roles

  • Driver: TC
  • Minutes: Tomas

Calendar

Background on planning

TC: Due to the edition, we spent much of 2024 on edition work, and between that and the holidays, we got rather behind on other things. We've been paying that down and have barely done any design meetings so far this year.

Champion system update / decision making

Niko: There are some documentation updates I want to make about the champion system. On the decision making PR, I had a discussion with Josh, and I want to summarize his point of view there.

Niko: Wants to bring our decision making process to a conclusion.

TC: There are some tweaks I'd like to see to that. I've left comments on the PR. We can discuss.

Niko: Want to put this on a doc and then schedule the discussion.

nikomatsakis takes some notes

Things on my mind that might benefit from wider discussion:

  • Decision making process PR.
  • Champion updates (probably better to wait till there is a PR on this, unclear that sync discussion is needed).
  • "Thoughts on ergonomic ref-counting" – maybe I'll just make a blogpost to start though.
  • "Thoughts on AFIDT" – errs and I (and prob others) have done some design work here that would be worth circulating.

Proposed meetings

  • "discuss/resolve fn { mod { (use) super::...; } } and its interaction with derive patterns" #193
  • "Design meeting: Rust issues encountered by new Rust users in the Bevy project" #229
  • "Design meeting: Let chains, guard patterns, and is; oh my!" #278
  • "Discuss agendas for Rust All Hands" #279
    • We can remove this.
  • "Alternative model for pattern matching and match ergonomics" #280
    • Nadri: I'm working on an RFC, I think we can remove this for now. I'll check with Waffle about this proposal.
  • "Design meeting: Async iteration (part 1)" #284
  • "Design meeting: Trait method impl restrictions" #288
  • "Design meeting: Discuss improvements to stabilization procedures" #302
  • "Design meeting: SIMD multiversioning" #309
  • "Design meeting: macro_metavar_expr" #310
  • "Design meeting: anonymous_lifetime_in_impl_trait" #311
  • "Design meeting: let chains" #312
    • it's stable!
  • "Design meeting: Implementable trait aliases" #322
  • "Design meeting: Solution for NoCell and no_std" #324
  • "Design meeting: #[align(..)]" #327
  • "Design meeting: Unsafe set enum discriminants" #329
    • Nadri: I'm interested in this

Please update these in https://github.com/orgs/rust-lang/projects/31/views/7.

is?

TC: We've done 2/3 things in:

https://github.com/rust-lang/lang-team/issues/278

We've stabilized let chains, and we've accepted the RFC for guard patterns. The last one is is. Where are we on this, Josh?

Josh: I still think there's a lot of value in adding is. I wonder about appetite from others here.

Josh: We've done the work to make let chains viable. We're shipping it in 1.88. What syntax will we pick for it? Libs folks asked for it – eliminates a lot of helper functions that libs regularly adds and other folks in the ecosystem regularly add.

Tyler: I like the idea. Feels premature to ship at this point.

Tyler: Some folks will complain because they "like that there's only one way to do things in Rust", but that's not true today anyway.

Josh: Given the proposed syntax uses a new keyword, it wouldn't go "into the language" in the 2025 edition.

TC: I have appetite for it.

Tyler: We can probably do more to unify let chains.

Niko: Feel like we've been moving to: once this is implemented, we're ready to stabilize. I want to play with it before stabilizing. Do we need a vibe check rather than a design meeting?

TC: +1.

Josh: An experiment would be valuable, but the delta from let chains to is is large enough that we should have an RFC before shipping it. Don't expect that this would be implemented and then stabilized right away.

Niko: Broader question: what is the general pattern for how we stabilize things. What is it we're doing that we're waiting for? If we want an experimental period, we should set a timer / describe the criteria.

TC: I've been happy with what we've been doing with the RFC happening later on the basis of an experimental implementation. It makes the RFC better, and it aligns with what we're doing with the champion system.

Nadri: Does anyone want to take on the lead on the implementation?

Josh: Prepared to be the champion and invest time from the language time working with the implementer. Not ready to lead the implementation though.

Nadri: Have an implementor in mind, going to ask.

Anonymous lifetime in impl Trait

https://github.com/rust-lang/lang-team/issues/311

TC: This is on our nominated queue as well. What do we want to do about that, e.g. Niko?

Niko: There's ambiguity here. We can say: someone (Niko or Tyler) go back to the thread and see if we can do a subset. The for syntax is not it.

Josh: Writing code in production, I've hit this error personally already. Would like that error to go away.

Niko: Papercut that sucks that we want to fix. Gather data on where named lifetimes are used in impl traits are in practice and where they're bound. Design work is needed.

Const trait impls

Tyler: What's the status on const trait impls proposal and nightly SIMD version. Is it realistic to have a design meeting on that?

Niko: We could do that (const trait impls) in two weeks. Let people refresh on the topic. The implementation is there. Blocked on discussion and bandwidth.

TC: We'll pencil this in for the 18th.

Declarative macro_rules! attributes and derives?

Josh: Stymied about how to move forward with this project goal. Working with a couple of folks building prototype implementations. Wondering what it'd take to unstick the actual RFCs. Expecting we could get a review on the RFC itself rather than being blocked on the implementation.

TC: Where did we land on RFC 3715?:

https://github.com/rust-lang/rfcs/pull/3715

We did a bikeshed and proposed FCP… it looks like it's still blocked on the concern tmandry raised.

Josh: The primary one is the attribute and derive using macro_rules!. Last time we scheduled a design meeting, the why not was unclear.

Tyler: Was looking for for: "this is a use-case the RFC supports sufficiently"

Josh: As a result, we put concrete examples into the motivation.

TC: Procedurally wants to resolve that first.

Josh: Wants the attribute and derives one resolved (3697 and 3698) first. 3715 isn't a blocker for either.

TC: The one we have most context on is 3715. Want to clear the queue here.

Josh: The original ask was to write all the RFCs. Now that that's done, they're clogging the queue? Want to get attribute and derives – those should have copious evidence.

Tyler: Which examples are you referring to?

Josh: The prior art section has the examples. There are speficic macros in the ecosystems people wrote as attributes that there's a cumbersome way of taking a proc macro and turning it into an attribute.

Niko: Being able to use both macro systems in the various systems. What's the argument for not having them consistent.

Josh: The only reasonable argument is: if this exists, would people feel pressured to using even if the proc macro can be easier. But the fact that there are macros today people have written sounds like a sufficient motivation.

Josh can update the RFC to link it better.

Niko: What is the threshold for going ahead and implementing it? I'm in favour of Josh building this out.

Josh: Last time this came up there was pushback on whether this is motivated.

Niko: You're looking for an agreement that this is a problem worth solving?

Josh: Agreement this is worth solving approximately this way (i.e. not a push-back for a fundemental level).

Niko: That seems like the right threshold for accepting the RFC.

Josh: Will update the RFC to make the examples more prominent. Nominating them to get the check-boxes.

TC: That sounds reasonable.

Niko: Our processes suggest infinite bandwidth (which we don't have). This is a goal, we want to move it forward. The frustration is understandable.

Josh: Plenty of people experience this and I don't want to be able to get through just because he's on this meeting.

SIMD

TC: Going back to this for a moment…

Tyler: What's the status on const trait impls proposal and nightly SIMD version. Is it realistic to have a design meeting on that?

TC: Right now we accept this on trait mehods that have default bodies and don't accept on trait methods without default bodies.

trait Tr {
    #[target_feature(enable = "avx2")]
    fn f();
}

impl Tr for () {
    #[target_feature(enable = "avx2")]
    fn f() {}    
}

Niko: Wasn't sure whether he was hitting the usecases people care about.

TC: I'd like to consider this in the same breath as const trait impls. In some ways, even, it seems a better starting problem for effects work.

Niko: We should address both. Happy if the scope of the meeting in two weeks would cover both and look at their scope and interaction. It raises syntactical questions that we wouldn't have to deal with if we just focust on const trait. But that's the point, isn't it.

TC: Yes.

Tyler: This is motivating to me too.

TC: After we talked, veluca93 ended up filing RFC 3820 that starts to document the shape of the problem here.

Solution for NoCell and no_std" #324

Niko: If we had a Unique<T> type we'd be happy. Stabilize the unique type?

TC: That would be my preference.

Implementable trait aliases" #322

Taylor: Tyler and I talked about this. A lot of questions, no specific proposal. Write a doc to list these more clearly?

TC: We've never sat down and reviewed the RFC yet.

Tyler: Taylor and I could collaborate on this.

Taylor: I can begin writing a doc. Would love to see the different approaches.

Josh: Libs would like one or more features in this area. We have traits in the stdlib that we have to get perfect at the first time. This would help us refactor traits later on. Would let us experiment with numeric towers, collection traits etc. Blanket impl is not quite good enough – people may want to implement one and to the other.

Taylor: I'd like to implement a sub trait and get supertrait for free.

TC: Among other things, this allows a migration path for relaxing the bounds on an associated type.

Niko: Happy for Taylor to pursue this.

Taylor: Getting an overview and look at it holistically would be useful.

Jubilee: We have some very specific instructions for what order you implement Ord, PartialOrd, and PartialEq in, in std. The world won't end if people have to follow those magic instructions but it definitely isn't making the language easier to use.

2025 H2 Project Goals

Niko: Want to do a slightly different process this time. Going to hand off the prioritization re: lang team resources to Tyler. We should have a meeting on it.

Tyler: We need to collect project goal proposals. Niko / project goals team will flesh those out a bit. The whole team will review them. 2025-06-25 too early.

TC: How are we managing the project goals team work?

Nico: Mostly async for now.

TC: What's the timeline for having inputs for lang?

Nico: Don't know yet.

Rust issues encountered by new Rust users in the Bevy project" #229

Josh: We invited Bevy to bring issues from new Rust users to us. They provided the list and we haven't looked at it. We should take a look at the list again and come back to them.

Jubilee: In addition to having new Rust users they also have issues with using the type system. Even if the user stuff is a bit dated, they're still pushing the bounds of the type system. We really should talk to them.

Josh: Example that came up during the Rust Week. If you can't implement a trait because one item in a fourteen-item tuple doesn't implement it – be really nice if the error message pointed which one it is.

Niko: We could do this either in July (Niko won't be there, that's ok) or interview them as part of the Vision Doc.

Josh: ¿Porque no los dos? Makes sense to do this as part of the vision doc experience. Value from hearing from them as a team rather than just individuals.

Tyler: Has anyone looked at the feedback lately? Is it still relevant after 2 years?

Josh: Last time I looked it, yes. We should look again before talking to them.

Tyler: What would be the desired outcome from the meeting?

Josh: An improvement of our baseline model of new Rust users. And a pile of notes of specific things that may be useful to fix (and possibly input for project goals).

TC: There should be a document that collects this.

Jubilee: I'll go dredge that document into being.

Niko: The goal is to hear and think and plant seeds. We don't necessarily need an outcome.

Tyler: Having data on the model for new Rust users would be great.

Josh: The recent fly.io article on locking showed that our fix to the if let issue for mutex fixed something that was genuinely helpful to people.

#[align(..)]" #327

TC: On our request Jules put up an RFC. I've reviewed it and proposed FCP merge. Do we need a design meeting?

Tyler: Design meeting as a means of forcing to read the RFC is something we've done before.

TC: Let's do 2025-07-02 then.

Niko: I don't need to be here for it.

Josh: If it's in FCP by the time of the meeting, we can use the meeting for something else.

Active initiatives

"project-safe-transmute" lang-team#21

Link: https://github.com/rust-lang/lang-team/issues/21

"const-evaluation" lang-team#22

Link: https://github.com/rust-lang/lang-team/issues/22

"const-generics" lang-team#51

Link: https://github.com/rust-lang/lang-team/issues/51

"Deref patterns" lang-team#88

Link: https://github.com/rust-lang/lang-team/issues/88

Nadri: FYI I'm still on this; implementation work is basically done, experimentation was helpful, and in the process of writing up an RFC based on that.

"Generators (iterator functions), sync and async" lang-team#137

Link: https://github.com/rust-lang/lang-team/issues/137

"Initiative: trusted external static declarations" lang-team#149

Link: https://github.com/rust-lang/lang-team/issues/149

Pending proposals on the lang-team repo

None.

Last changed by 
 
Rust Lang Team
Language Design team for the Rust programming language
0
118

Read more

Triage meeting 2025-06-25

Meeting date: 2025-06-25

Jun 26, 2025
Design meeting 2025-06-25: Bevy

Bevy is a data-driven game engine that is implemented primarily as a Rust library crate. It uses the pattern of having a "façade" crate.

Jun 26, 2025
Volunteers for `lang-interest`

Sometimes, particularly on stabilizations, the lang team would like to have more eyes on certain PRs. While we do try to ping those we can think of that have knowledge and interest in the item, often that still leaves only a handful of people that have been specifically notified about what might be a consequential stabilization or other matter.

Jun 25, 2025
Lang/RfL meeting 2025-06-18

People:

Jun 19, 2025
Read more from Rust Lang Team
Published on HackMD