---
title: Planning meeting 2024-02-07
tags: ["T-lang", "planning-meeting", "minutes"]
date: 2024-02-07
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings
url: https://hackmd.io/bXPp5C4HSAGTBim69nPkCw
---

# T-lang planning meeting agenda

- Meeting date: 2024-02-07

## Attendance

- People: TC, Josh, nikomatsakis, tmandry, pnkfelix, CE, Vincenzo

## Meeting roles

- Minutes, driver: TC

## Proposed meetings

- "Nail down cargo-script syntax proposal" [#232](https://github.com/rust-lang/lang-team/issues/232)
- "We need to settle the behaviour of floating-point in `const`" [#222](https://github.com/rust-lang/lang-team/issues/222)
- "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" [#193](https://github.com/rust-lang/lang-team/issues/193)
- "Design meeting: Rust issues encountered by new Rust users in the Bevy project" [#229](https://github.com/rust-lang/lang-team/issues/229)
- "Design meeting: Profiles" [#245](https://github.com/rust-lang/lang-team/issues/245)
- "Discuss feedback for T-spec sample chapters" [#250](https://github.com/rust-lang/lang-team/issues/250)

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

## Dates

- 14th -- :heartbeat: Valentine's day :heartbeat:, should avoid meeting unless we have to.
- Temporary lifetimes, due to edition sensitivity.
- 21st
- T-spec feedback.
- 28th
- Arbitrary self types v2.

JT: In the T-spec feedback session, we can collect both individual and consensus feedback.

## RTN

NM: Do we want another meeting on RTN?

JT: We probably want smaller meetings. I'd like a smoketest on the alternative proposal and then I'd be willing to write up both an "issues with RTN" doc and a more concrete alternative proposal.

## Other RFCs

NM: Anything else, TC, we might think to discuss, in terms of open RFCs?

TC: The provenance RFC seemed interesting to people, but isn't edition relevant. The `Range` types is edition-relevant, and could make a good meeting.

https://github.com/rust-lang/rfcs/pulls?q=is%3Apr+is%3Aopen+label%3AT-lang

NM: It'd be good to get people from T-libs-api for that call.

## Spec

pnkfelix: We should discuss the guidance for the spec. I'll write a document for that, and it'd be good to have a date. Design meetings act as a forcing function to cause people to come to the table.

## Temporary lifetimes

NM: The temporary lifetimes proposal is also edition relevant and is likely to result in a proposed RFC soon. A design meeting could act as a forcing function.

JT: Has the feedback on syntax been processed such that the design document will cover the syntax alternatives? I'm asking to make sure the design meeting does not spend time on bikeshedding syntax proposals and the tradeoffs between them; if we have those already covered we can avoid doing design-in-the-meeting and focus on semantics.

(Discussion on the semantics.)

TC: Here's the semantic idea, boiled down to an equivalence:

{ super let VAR = EXPR; &VAR }
------------------------------
&EXPR

## Bevy feedback session?

(Short discussion about the merits of this.)

## Scheduling RfL meeting

TC: We need to schedule the next meeting with the RfL team. Here's the discussion of that:

https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-02-06.3F

Here's where people filled in their schedules:

https://lettucemeet.com/l/R8vBx

TC: Here's an analysis of that:

Looking at the details that people have posted, some observations that may help inform what is in the realm of the feasible:

- People in Europe (reasonably) tend to want to avoid 1-hour slots starting after <time:2024-02-06T20:00:00Z>.
- People on the US West Coast (reasonably) tend to want to avoid starting meetings before <time:2024-02-06T16:00:00Z>.
- Many people are heavily booked on Wednesdays.
- Many people also have limited Friday availability.

If we exclude the times don't work for Europe and don't work for the West Coast, then that leaves four one-hour slots (two on each of Tuesday and Wednesday) that appear to work for at least three T-lang{-ops} members, and one single one-hour slot that works for four T-lang{-ops} members.

The slot that works for all members who have replied is the <time:2024-02-07T17:00:00Z> slot between our triage and design meeting calls. Unfortunately that slot seems bad for many people on the RfL side.

The other slots with more limited overlap on the lang side and not too early or late are:

- <time:2024-02-06T16:00:00Z> (conflicts with T-libs-api call)
- <time:2024-02-06T20:00:00Z>
- <time:2024-02-07T20:00:00Z> (conflicts with T-style call half an hour in)

We'll probably need to discuss this on a T-lang call to work out how to best balance these concerns and to propose a time for this call.

NM: Alice seems to be the key person for `Arc`.

(Discussion about whether meeting in person at RustNation or RustNL may be valuable and possible.)

JT: We do need a solution for the ongoing collaboration.

(Discussion about whether we may want to hold these calls quarterly.)

TC: We should follow through on what we said we'd do and set up a meeting soon. Such a meeting may help determine what needs to happen after that.

JT: Noon Pacific on Monday the 12th, 2000 UTC?

NM: +1, and we should create an agenda for it.

TC: I'll announce that time on thread.

## RTN gut check on alternate proposal

TC: We have 10 minutes to get the gut check Josh wanted on his proposed alternative to RTN.

NM: Is this the proposal?:

trait Foo<trait MaybeSend = ?Send> {
    type X: Bar + MaybeSend;
    fn something() -> impl Future<...> + MaybeSend;
}

JT: `Foo` or `Foo<?Send>` would have a concrete meaning; `Foo<Send>` would have a different concrete meaning.

NM: This is higher order predicates. This is a big step up in complexity from what we do. When you have to infer the bounds that go there, that would be challenging.

NM: I have concerns that this will take us a long time to flesh this out and stabilize. Separately, I don't think this covers all of the design criteria.

TC: There is overlap between the RTN decision and the ongoing work on maybe `const`. That work has been going in the direction of using a single trait (without new generics on the trait) and adding associated constants on it and adding const generics for each method. That design fits better in an RTN world than in e.g. a trait transformer world.

JT: There does seem some similarity there.

TC: It would seem very inconsistent for us to do one thing here and another there.

JT: +1.

TC: Separately, here's another angle that may be worth dicussing in any document:

In a world with RTN, we could write:

trait Service {
    fn send(&mut self) -> impl Future; // Note no ATs specified here.
    fn recv(&mut self) -> impl Future;
}

In a world without RTN, I'd want the trait author to instead write, e.g.:

trait Service {
    type SendOutput;
    type SendFuture<'a>: Future<Output = Self::SendOutput>
    where
        Self: 'a;
    type RecvOutput;
    type RecvFuture<'a>: Future<Output = Self::RecvOutput>
    where
        Self: 'a;
    fn send(&mut self) -> Self::SendFuture<'_>;
    fn recv(&mut self) -> Self::RecvFuture<'_>;
}

In general, the rule without RTN is, "please copy all of the associated types connected with the return type of your methods onto the trait".

If, just as we tell people to not return RPIT opaque types across APIs, we tell people writing public traits to always write the latter rather than the former, then the result is equally expressive. So it comes down to a question of if that's what we want to tell people to do, or whether we want to support people writing the former.

Tyler: Generally, I feel like the framing of "which use cases are covered and which aren't" is not the right framing?

(The meeting ended here.)

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

## Pending proposals on the lang-team repo

None.

## Pending PRs on the lang-team repo

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

### "clarify lint policy " lang-team#48

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

### "const-generics" lang-team#51

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

### "Make a place for a "lang team wishlist"" lang-team#54

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

### "Link in design meeting template is dead" lang-team#80

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

### "Eventual Concern: Send/Sync insufficient in the presence of multiple execution contexts." lang-team#87

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

### "Deref patterns" lang-team#88

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

### "Specification of safe rust ?" lang-team#123

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

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

### "agenda generation should include section with S-waiting-on-team + T-lang" lang-team#172

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

### "dead Zulip/zulip-archive links" lang-team#185

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

### "HTTP Error 404 in the Chat Platform p link" lang-team#186

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

### "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" lang-team#193

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

### "lang agenda generator ignores lang-nominated closed issues" lang-team#199

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

### "mdbook build and deploy is failing" lang-team#221

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

### "We need to settle the behaviour of floating-point in `const`" lang-team#222

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

### "Design meeting: Rust issues encountered by new Rust users in the Bevy project" lang-team#229

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

### "Nail down cargo-script syntax proposal" lang-team#232

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

### "Add soqb`s design doc to variadics notes" lang-team#236

**Link:** https://github.com/rust-lang/lang-team/pull/236

### "Update auto traits design notes with recent discussion" lang-team#237

**Link:** https://github.com/rust-lang/lang-team/pull/237

### "Lang-team RFC guidelines appear to be out of date" lang-team#244

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

### "Design meeting: Profiles" lang-team#245

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

### "Discuss feedback for T-spec sample chapters" lang-team#250

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

### "Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }`" lang-team#251

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

### "Notes from my RFC experience" lang-team#252

**Link:** https://github.com/rust-lang/lang-team/pull/252