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 (#223)
• 2023-10-18
  • Scheduled: "Design meeting: Decide about the future for consts in patterns" #220
  • RalfJ confirmed his availability.

• 2023-10-25
  • Scheduled: Implementable trait aliases - #3437 (#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
  • "We need to settle the behaviour of floating-point in const" #222
• "2023 roadmap update" #188
• "discuss/resolve fn { mod { (use) super::...; } } and its interaction with derive patterns" #193

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

Proposed RFC reads

• Unsafe extern blocks - #3484
• Placement by return - #2884
• Implementable trait aliases - #3437
• UnsafeAliased - #3467
• Unsafe lifetime - #3199
• Aligned trait - #3319
• Add bf16, f64f64 and f80 types - #3456
• Unified string literals - #3475
• Code string literals - #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 – const in patterns, gotta get that done! I'm so sick of talking about this.
• Placement by return - #2884 – relevant to AFIT, RPITIT.
• UnsafeAliased - #3467 – this seems like a fundamental step fwd, opsem team?
• Unsafe lifetime - #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 – seems like a small change, maybe a win?
• Code string literals - #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 – I'm sure this is important. I just have very little to add.

Felix

• Interested in #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!
• 3484 (unsafe extern blocks) 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.
• 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

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

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
• Link: Code string literals - #3450
• Prior discussion: pre-RFC: Extend Hash-sequences to all String Literals
• Prior art: C# - Raw string literal text - """ in string literals
• Prior art: C# - Tutorial: Write a custom string interpolation handler
• Prior art: Swift - Enhancing String Literals Delimiters to Support Raw Text

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

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 on GitHub for the schedule, since that's what is pulled in by 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 links to the calendar 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