Planning meeting 2023-10-04

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