---
title: Planning meeting 2025-08-06
tags: ["T-lang", "planning-meeting", "minutes"]
date: 2025-08-06
discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Planning.20meeting.202025-08-06/
url: https://hackmd.io/Zbw8tU_ESaegXzSxhWRR1Q
---

# T-lang planning meeting agenda

- Meeting date: 2025-08-06

## Attendance

- People: TC, Niko, Taylor Cramer, Tomas Sedovic, Josh, Yosh, Eric Holk, scottmcm, Benno Lossin

## Meeting roles

- Driver: TC
- Minutes: Tomas Sedovic

## Calendar

- 2025-08-06
- Planning (today)
- 2025-08-13 (Niko out)
- "Design meeting: Field Projections" [#335](https://github.com/rust-lang/lang-team/issues/335)
- 2025-08-20
- "Design meeting: Extending const generics -- constraints and tradeoffs" [#340](https://github.com/rust-lang/lang-team/issues/340)
- 2025-08-27
- "Design meeting: Ergonomic ref-counting" [#343](https://github.com/rust-lang/lang-team/issues/343)
- 2025-09-03 (Niko out)
- "Design meeting: Review RFC 3804 `cfg_alias`" [#345](https://github.com/rust-lang/lang-team/issues/345)
- 2025-09-10 (Josh out)
- "Design meeting: Extending const generics -- temperature check" [#341](https://github.com/rust-lang/lang-team/issues/341)
- 2025-09-17 (Josh out)
- "Design meeting: Unsafe fields RFC review" [#344](https://github.com/rust-lang/lang-team/issues/344)
- 2025-09-24
- "Design meeting: Wasmtime team sync" [#342](https://github.com/rust-lang/lang-team/issues/342)
- 2025-10-01: Next planning meeting

## Project goals update

See https://docs.google.com/spreadsheets/d/1Y3xXWMwtT_gX20ILZ3noZRZyTVRkWGGTtTpfoaoeXyo/edit?gid=1018626522#gid=1018626522

Some things to discuss:

* [Delegation -- no champion](https://github.com/rust-lang/rust-project-goals/blob/main/src/2025h2/delegation.md)

Niko: I'm planning to prepare the revised RFC hopefully today. Most of the goals that were proposed had champions. With the notable exception of the Delegtaion proposal. As it stands I plan to drop it. My expectation for champion: make sure any major decisions get updated on the tracking issue and you're able to discuss them in the meeting if someone has questions.

Josh: I'd love if we can get Delegation moving. Maybe we can ping our lang-advisors -- they can be champions.

Josh: The project goals tend to run behind schedule in terms of shipping things. A painful side effect is that until the goal is accepted, we can't start the coordination process (repository, channel). Obviously if a goal isn't accepted this it shouldn't use the Rust's official places. But moving repos is annoying. And GitHub repo moves can't move a project board.

TC: What's the connection between project goal being accepted and the repo being in rust-lang?

Josh: That was the policy in the past: you could have a repo only once a goal was accepted.

Niko: I still plan to stick to the schedule (for the RFC to be accepted by 2025-09-01). If you have specific projects and you have champions, it's okay to open the repos.

Josh: That would be fine. I'm more broadly making the observation that the names like 2025H2 start to be problematic when it startts too late.

Niko: I can ping lang-advisors about Delegation. Josh: are you interested?

Josh: I care about it and I'm interested in it. But I don't think I'm equipped to be the person reporting the status to the lang team.

Taylor: I'm willing to do the work of relaying updates. But my experience working on delegation before was: there was a large scope of features to be implemented and the large scope.

Niko: Maybe the answer is we're not ready to move it to a stabilization-ready state and we'd prefer a more narrow RFC.

Niko: I feel in this particular case the lang champion might be more involved.

Josh: I think in this case a big responsibility for the champion would be scope management.

Niko: I'll leave a comment saying we don't have a champion, I'll ping the advisors.

Taylor: I'm not saying I'm not willing to do it. I'm just sceptical that it can be done successfully.

Niko: You're saying you wish the scope were more narrow? Rather than just "implement the RFC".

TC: That sounds like the perfect role for the champion -- working with the project owner to narrow the scope.

Taylor: What is the feature actually? It gets more difficult on enum variants, delegating through a reference, etc. I'm confident you could write `decltype` using this.

Niko: It sounds that the scope is too large to get done. If I had to trade this out for almost anything else on the list, I'd probably still say no. Not a fundamental enabler. It's the feature you wish you had but you're not shocked that it's not there.

Taylor: It's the sort of thing I wish you could write a macro for but you can't.

Niko: We need a clearer scope and motivation in the moment. Doesn't mean they can't pursue it -- just that we don't guarantee to spend the resources on it.

Niko: All af the design meeting asks from the goals look good.

TC: Anything from the project goal that wants a design meeting, we need to make sure that gets filed as a design meeting proposal.

Niko: I want to have one on ergonomic ref counting.

Yosh: Proposal: I work with the WASM folks and asked them what they need from the Rust language. Maybe do a similar session to Bevy with the wasmtime folks.

TC: Propose that as a design meeting if you would.

Josh: I'd prefer to have the WASM one on a date I'm available.

TC: On pin ergonomics, we're letting that experiment go forward a bit further. It'll come back later.

Niko: We just had in-place init. I don't think there's a lot to take away but I don't think we need another meeting now.

TC: Niko and I should talk about pin ergonomics about the negative ("never" ) impl.

Niko: I want to talk about pin ergonomics and I think Josh would be interested.

Josh: I'd propose having a wasmtime session on what they need from us is really useful but not urgent. Ergonoming ref counting is a goal so we should do it sooner.

TC: What's the plan on ergonomic ref counting?

Niko: The experiment has more or less landed. My plan was to summarize the RFC, feedback, propsal.

TC: Is this you writing up the design doc?

Niko: Yeah. Two things to discuss: the basic shape of the design and what we're trying to achieve. And then specific issues that came up during the implementation - interactions with the unsafe work.

TC: wasmtime, what's the meeting about?

Yosh: The meeting is mainly to provide feedback. The wasmtime team is mostly composed of previous Rust language folks. They want to talk about what they're hitting.

TC: Would this be kind of like the bevy call? Where someone's going to put like an experience report?

Yosh: That's what I was thinking. I'd write the doc.

Josh: It's worth noting that Rust has been one of the biggest influences on the design of webassembly. WASM might be one of the first cases where Rust was on par or beyond C/C++ in defininng how things work. So we should give serious considerations.

Josh: Yosh, are you part of the regular wasm Saturday meetings?

Yosh: No.

Josh: There's a regular wasm meeting. The WebAssembly Community Meetings.

Yosh: I believe they're on Tuesdays. I sometimes go there.

Josh: It'd be a good idea to go to one of those meetings and actively solicit the group for that.

Yosh: 100%.

Niko: Scott: unsafe fields -- do we need another meeting?

Scott: Last I saw they're waiting on Lang feedback on something?

Scott: here's the link: https://github.com/rust-lang/rfcs/pull/3458#issuecomment-2825837922

Niko: That could be September 17th?

Josh: Unsafe fields is fine to do while I'm not here. I'm interested, want to see it ship but it can move without me.

Benno: Field projections would be great to have soon. There are several different things I'd like some input from t-lang on and I'm kind of stuck depending on the answers.

Josh: Could we make things as early as next Wednesday?

Benno: In theory I could, but it might be tough for Tyler.

Josh: Could you check with Tyler and we'll schedule it tentatively?

TC: There's been movement on explicit tail calls. The thread's been moving slowly. There is work to update the RFC with what has been learned.

Josh: Glad to hear that.

TC: Scott, where are we with unsafe fields?

Scott: I need to re-read the RFC to confirm. The biggest consideration is what do we expect the main speace to be. IIRC it's gon in the direction of: anything other than a place mentioned in the field becomes unsafe. That's straightforward. But it also feels like not something any of the unsafe code wanted that version. The common case is: I have a bunch of ordinary primitives and there's tricky variance between them. But you can read them no problem. What do we feel is the intent here and is this a fine starting point? Are we okay with the direction? Would we like a slightly noisier way of specifying that everything is unsafe. As a lang team I think we agree something here is absolutely wanted, but how do we feel about the phrasing of this.

TC: We'll put this on the 17th.

Scott: I'd be happy to stick my RFC in there if people are happy with that. The question is: do we think that code that's currently written to mention transmute without calling it is correct to be relying on the compilation error in that case.

Josh: You're talking about the idea of by referencing transmute with specific generic idea to ..

Scott: exactly.

Josh: First, we've never made any promises to what compiler would check there. We could decide to remove all the restrictions on transmute and that would also have been a valid change. And that would be OK. We're talking about making it more strict and that's fine too.

Scott: someone mentioned one other library doing that trick and that library stopped doing that trick.

Josh: I think we need to make sure we coordinate this with the libraries, but after that we're fine shipping it.

Scott: I agree with everything you said. If there's a lot of people who had a lot of disagreements, that's what we'd discuss here.

Josh: I'd explicitly call this out when we do `@rfcbot merge`.

TC: I'm looking down the list of other plausible RFCs. There's one about naming groups of configuration with `cfg_alias`. RFC 3804: https://github.com/rust-lang/rfcs/pull/3804. I'll file a design meeting proposal.

Josh: I just nominated one item for vibe check. It's `repr(linear)`.

Scott: I haven't read the RFC but if it's about whether we should have repr(linear), checkbox approved.

TC: I'm going to propose RFC 3804`cfg_alias` for 2025-09-03.

Scott: Sounds good. We've talked about this being a feature so if we have an RFC for that would be great.

Scott: Another one that had a lot of activity: the one about safety tags. Addressing area that I think is really important. We could have a lang conversation about that at some point in the future.

Josh: We definitely should have a lang conversation about that. We could have a have a vibe check during lang triage. But given the 100+ comments in the last week seems that it's not settled yet. But we could do a vibe check.

Scott: Agreed

Josh: Another small item: RFC 3796 (allowing `||`/`&&`/`!` in `cfg`) https://github.com/rust-lang/rfcs/pull/3796

TC: I had left a comment that still represents the state of my thinking there:

https://github.com/rust-lang/rfcs/pull/3796#issuecomment-2993831077

TC: I'll say too that what I'd really like, ideally, is a `cfg`-like attribute that would be evaluated by const-eval without anything from the current crate being in scope. Then the attribute could just use Rust syntax. We'd have some const-compatible `HashMap`-like type for making the `cfg`-options available. I floated this to some people.

---

TC: OK. We have all the weeks scheduled. We're good to go.

(The meeting ended here.)

## Project goals

### actionable

* [x] Const Generics
* Ergonomic ref-counting: RFC decision and preview -- nikomatsakis

### unclear

* Unsafe Fields ??
* Design a language feature to solve Field Projections
* Nightly support for Autoreborrow traits (↳ Implement non-recursive autoreborrowing)

### not yet actionable

* reflection and comptime -- design
* In-place initialization
* Continue Experimentation with Pin Ergonomics

## Proposed meetings

- "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" [#193](https://github.com/rust-lang/lang-team/issues/193)
- "Design meeting: Let chains, guard patterns, and `is`; oh my!" [#278](https://github.com/rust-lang/lang-team/issues/278)
- "Design meeting: Async iteration (part 1)" [#284](https://github.com/rust-lang/lang-team/issues/284)
- "Design meeting: Trait method impl restrictions" [#288](https://github.com/rust-lang/lang-team/issues/288)
- "Design meeting: Discuss improvements to stabilization procedures" [#302](https://github.com/rust-lang/lang-team/issues/302)
- "Design meeting: SIMD multiversioning" [#309](https://github.com/rust-lang/lang-team/issues/309)
- "Design meeting: `macro_metavar_expr`" [#310](https://github.com/rust-lang/lang-team/issues/310)
- "Design meeting: `anonymous_lifetime_in_impl_trait`" [#311](https://github.com/rust-lang/lang-team/issues/311)
- "Design meeting: Interop, part 2" [#316](https://github.com/rust-lang/lang-team/issues/316)
- "Design meeting: Solution for `NoCell` and `no_std`" [#324](https://github.com/rust-lang/lang-team/issues/324)
- "Design meeting: Field Projections" [#335](https://github.com/rust-lang/lang-team/issues/335)
- "Design meeting: `cfg_version`" [#337](https://github.com/rust-lang/lang-team/issues/337)
- "Design meeting: Explicit tail calls" [#338](https://github.com/rust-lang/lang-team/issues/338)
- "Design meeting: Extending const generics -- constraints and tradeoffs" [#340](https://github.com/rust-lang/lang-team/issues/340)
- "Design meeting: Extending const generics -- temperature check" [#341](https://github.com/rust-lang/lang-team/issues/341)
- "Design meeting: Wasmtime team sync" [#342](https://github.com/rust-lang/lang-team/issues/342)
- "Design meeting: Ergonomic ref-counting" [#343](https://github.com/rust-lang/lang-team/issues/343)
- "Design meeting: Unsafe fields RFC review" [#344](https://github.com/rust-lang/lang-team/issues/344)
- "Design meeting: Review RFC 3804 `cfg_alias`" [#345](https://github.com/rust-lang/lang-team/issues/345)

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

## 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

### "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