---
title: Planning meeting 2023-10-04
tags: T-lang, planning-meeting, minutes
date: 2023-10-04
discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Planning.20meeting.202023-10-04
url: https://hackmd.io/Mn-YePbCRc2eYFS30inoww
---

# T-lang planning meeting agenda

- Meeting date: 2023-10-04

## Attendance

- Team members: tmandry, nikomatsakis, pnkfelix, scottmcm
- Others: TC, waffle, Jubilee

## Meeting roles

- Minutes, driver: TC

## Dates, availability, scheduling

- 2023-10-11
- Scheduled: [Unsafe extern blocks - #3484](https://github.com/rust-lang/rfcs/pull/3484) ([#223](https://github.com/rust-lang/lang-team/issues/223))
- 2023-10-18
- Scheduled: "Design meeting: Decide about the future for consts in patterns" [#220](https://github.com/rust-lang/lang-team/issues/220)
- RalfJ confirmed his availability.
* 2023-10-25
- Scheduled: [Implementable trait aliases - #3437](https://github.com/rust-lang/rfcs/pull/3437) ([#224](https://github.com/rust-lang/lang-team/issues/224))
- NM: But either the RFC needs an update such that `trait A Foo + Bar` is supported if `Bar` is a marker trait (leaving the more general case for future work), or we add an addendum to this effect, which either NM or tmandry might write.

NM: Unavailable for 2023-10-11 meeting due to types team meetup.

Others: Free for all Wednesdays this month.

## Proposed meetings

- "Design meeting: Decide about the future for consts in patterns" [#220](https://github.com/rust-lang/lang-team/issues/220)
- "We need to settle the behaviour of floating-point in `const`" [#222](https://github.com/rust-lang/lang-team/issues/222)
- "2023 roadmap update" [#188](https://github.com/rust-lang/lang-team/issues/188)
- "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" [#193](https://github.com/rust-lang/lang-team/issues/193)

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

## Proposed RFC reads

- [Unsafe extern blocks - #3484](https://github.com/rust-lang/rfcs/pull/3484)
- [Placement by return - #2884](https://github.com/rust-lang/rfcs/pull/2884)
- [Implementable trait aliases - #3437](https://github.com/rust-lang/rfcs/pull/3437)
- [UnsafeAliased - #3467](https://github.com/rust-lang/rfcs/pull/3467)
- [Unsafe lifetime - #3199](https://github.com/rust-lang/rfcs/pull/3199)
- [Aligned trait - #3319](https://github.com/rust-lang/rfcs/pull/3319)
- [Add `bf16`, `f64f64` and `f80` types - #3456](https://github.com/rust-lang/rfcs/pull/3456)
- [Unified string literals - #3475](https://github.com/rust-lang/rfcs/pull/3475)
- [Code string literals - #3450](https://github.com/rust-lang/rfcs/pull/3450)

## Interest meter

Make a section and put in things that potentially interest you, and/or things you don't feel you need to be involved for.

### Niko

Would like to be involved in the discussion:

- "Design meeting: Decide about the future for consts in patterns" [#220](https://github.com/rust-lang/lang-team/issues/220) -- const in patterns, gotta get that done! I'm so sick of talking about this.
- [Placement by return - #2884](https://github.com/rust-lang/rfcs/pull/2884) -- relevant to AFIT, RPITIT.
- [UnsafeAliased - #3467](https://github.com/rust-lang/rfcs/pull/3467) -- this seems like a fundamental step fwd, opsem team?
- [Unsafe lifetime - #3199](https://github.com/rust-lang/rfcs/pull/3199) -- I've definitely hit this problem when writing unsafe code, and it's a real drag.

Curious to see discussed, don't know that I have to be involved:

- [Aligned trait - #3319](https://github.com/rust-lang/rfcs/pull/3319) -- seems like a small change, maybe a win?
- [Code string literals - #3450](https://github.com/rust-lang/rfcs/pull/3450) -- indentable strings feels like a real win, not sure if this is the right step forward exactly, kind of a "fun piece of candy".
- [Add `bf16`, `f64f64` and `f80` types - #3456](https://github.com/rust-lang/rfcs/pull/3456) -- I'm sure this is important. I just have very little to add.

### Felix

* Interested in [#220](https://github.com/rust-lang/lang-team/issues/220).
* Interested in maybe a combo meeting covering both of #3475 (unified string literals) and #3450 (code string literals). Main reason to have design meeting is to align team on our appetite for making any changes in this general space.
* Placement by Return #2884 -- main concern is whether doing this complicates solving more general problem (e.g. of returning a Result enum with different destination slots for the distinct variants).

### Scott

* [#220](https://github.com/rust-lang/lang-team/issues/220)!
* [3484 (unsafe extern blocks)](https://github.com/rust-lang/rfcs/pull/3484) looks like an edition thing, so we might want to look at it sooner rather than later.
* Unsafe lifetime is interesting -- it would be nice to be able to write things like `sizeof(slice::Iter<'!, T>)` without needing bounds on `T` -- but last I heard it was really hard to make sound, so might be a direction discussion instead.
* `bf16` and such I feel like I more want a "use literals with custom types" RFC first.

### Tyler

* [#220](https://github.com/rust-lang/lang-team/issues/220).
* Unsafe extern.
* Implementable trait aliases – but RFC needs an update.
* UnsafeAlias to complete the matrix – but Ralf might be busy this month with #220.
* Unsafe lifetime.

## Minutes

### Unsafe extern blocks

- Link: [Unsafe extern blocks - #3484](https://github.com/rust-lang/rfcs/pull/3484)

NM: Should we just FCP this?

tmandry: I'll do it.

Jubilee: There is an open concern about whether people will accidentally stabilize huge APIs.

NM: Maybe we should have a design meeting with a broader scope about overloading the `unsafe` keyword.

pnkfelix: Maybe there should be a lint.

NM: There is some subtlety there.

scottmcm: Maybe the `trusted` keyword would help here. One of the questions is whether we should require `safe fn`.

TC: We could FCP this, then also separately consider those things. If those other things take a long time or don't happen, maybe this is still a good idea on its own.

NM: That is the question. I find my enthusiasm is tempered by considering these other things.

scottmcm: The one thing that makes me pause is that it's not obvious what exactly is the transition mechanism.

TC: I've talked with Lokathor about this. He's aware he needs to add it to the document. It's clear what `cargo fix` should do here.

NM: It's probably worth having a meeting about this. Something like this is clearly the direction we want to go, but there are things to discuss.

### Aligned trait

- Link: [Aligned trait - #3319](https://github.com/rust-lang/rfcs/pull/3319)

Room: The RFC needs more motivation stated.

Jubilee: There is a deep motivation.

TC: Could you make a PR for that?

Jubilee: Yes, I can write that up.

### The string-related RFCs

- Link: [Unified string literals - #3475](https://github.com/rust-lang/rfcs/pull/3475)
- Link: [Code string literals - #3450](https://github.com/rust-lang/rfcs/pull/3450)
- Prior discussion: [pre-RFC: Extend Hash-sequences to all String Literals](https://internals.rust-lang.org/t/pre-rfc-extend-hash-sequences-to-all-string-literals/19300/1)
- Prior art: [C# - Raw string literal text - `"""` in string literals](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/raw-string)
- Prior art: [C# - Tutorial: Write a custom string interpolation handler](https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/interpolated-string-handler)
- Prior art: [Swift - Enhancing String Literals Delimiters to Support Raw Text](https://github.com/apple/swift-evolution/blob/main/proposals/0200-raw-string-escaping.md)

pnkfelix: We may want to talk about how much we want to invest in this space.

tmandry: I think I'm in favor of both of the RFCs.

pnkfelix: The unified string literals makes the raw string syntax redundant.

(Discussion about the scope of unified string literals.)

TC: One of the things we may want to discuss is the potential interaction with `format!`. In Swift, where this is pulled from, there is that interaction, and it's part of what makes it motivating in Swift.

(Discussion about that, about fstrings, etc.)

NM: Looking at the future possibilities, those seem more exciting to me. I see the motivation here.

tmandry: I kind of like triple quotes.

NM: If we do the unified string literals, I'd like to get rid of raw string literals to keep complexity down.

tmandry: Anyone want to talk me down from triple quotes?

TC: Do you mean three or more?

tmandry: Three or more.

scottmcm: The C# rule seems to be three or more.

TC: These seem to fall under the category of "dare to ask for more". There are some quality of life improvements possible here.

NM: fstrings are maybe worth thinking about. That's maybe a true "dare to ask for more". It would make it so much more ergonomic to get capital strings.

TC: Does that maybe encompass a `const` `format!` that produces a `&'static str'`?

NM: Interesting, yes, it could.

Jubilee: There are people who want it to be `String` and there are people who want it to be a language primitive. If you wind up with `String + format_args!/format_sting!`, you have to do an allocation and merge the two semantically. The people who want it to be `format_args!` care a lot about it not having extra allocations or use the `alloc` crate.

scottmcm: C# has `$`-strings which is a spin on `fstrings`.

TC: It does seem like a new design should take into account laziness.

NM: It does seem that this comes up a lot, and there are motivations for both. I'll leave [feedback](https://github.com/rust-lang/rfcs/pull/3475#issuecomment-1747380570) on the RFC for the unified string literals.

### Prioritizing things for 2024

scottmcm: These are potentially interesting, but they're not edition-dependent. We might want to prioritize the 2024 things.

TC: Maybe we should review the [2024 edition survey](https://hackmd.io/itGzgM1fQl-oh4d1iP8sFg).

### Publishing a schedule

NM: We should publish our schedule more widely. We have various places for it now. At one time we made blog posts.

TC: The source of truth is the [project](https://github.com/orgs/rust-lang/projects/31) on GitHub for the schedule, since that's what is pulled in by [triagebot](https://github.com/rust-lang/triagebot). I've been making certain improvements to triagebot; one is that it now shows the *dates* of the scheduled meetings on our agenda. It pulls this from GitHub.

tmandry: Our page for [design meetings](https://lang-team.rust-lang.org/meetings/design.html) links to the [calendar](https://lang-team.rust-lang.org/calendar.html) page which points to our Google calendar.

TC: Let's update that page to link to the GitHub project for the schedule.

tmandry: I'm doing that.

(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

### "Add size != stride to frequently requested changes" lang-team#216

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