Planning meeting 2023-09-06

--- title: Planning meeting 2023-09-06 tags: planning-meeting, T-lang url: https://hackmd.io/5lSKHhrUSoKQFpO90zrJfg --- # T-lang planning meeting agenda * Meeting date: 2023-09-06 ## Attendance * Team members: tmandry, Niko, pnkfelix, Josh * Others: TC ## Meeting roles * Minutes: TC ## Proposed meetings - "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. ## Scheduling - September 13 - tmandry not available - September 20 - nikomatsakis not available - pnkfelix maybe not available - September 27 - Josh traveling, unlikely to be available ## Ideas for design meeting - Maybe one for RPITIT? - Maybe the edition? Upcoming and planned stabilizations: * RPITIT, AFIT -- * Biggest question is whether it hinges on RFC for lifetime capture. * That RFC is in progress, gathering data. From the RPITIT design meeting minutes: > ### Question: Are we ready to RFC this? > > TC: If we were to propose an RFC with the text of this document, cleaned up lightly for the RFC format, and with the addition that Josh proposed (that if in the future we discover that too much code experiences overcapturing and needs to be desugared to TAIT, we should explore more ergonomic solutions), who here would check their box, by a show of hands? > > joshtriplett: Hand. > tmandry: Hand. > nikomatsakis: Hand. > pnkfelix: Hand. > > (scottmcm was not present in the meeting.) Niko: The biggest question is do we want some other syntax to control captures? But that doesn't seem like a blocker. Niko: Would anyone block RPITIT/AFIT on this? (Hearing none....) Josh: Let's just go ahead and do the FCP? Niko: The answer seems to be that we don't need a design meeting here. TC: The bigger risk for a design meeting on RPITIT were the changes to refinement, but we achieved consensus on how to move forward on that. --- Niko: Do we want a design meeting for the leadership discussion, choosing a new lang-team co-lead? But I'm not sure we need a meeting there yet. Some people did reach out to me about eventual lang-team membership. Expectations are laid out here: https://lang-team.rust-lang.org/membership.html#qualifications Niko: I suggest to people that they attend the attend to triage meetings and look for opportunities to drive initiatives forward. --- TC: Maybe we should discuss MaybeDangling during a design meeting. The RFC itself would be the design document; we'd just read that and then discuss it. There are other RFCs we might want to do this with. `MaybeDangling`: https://github.com/rust-lang/rfcs/pull/3336 Ralf has a related one for `UnsafeAliased`: https://github.com/rust-lang/rfcs/pull/3467 Lokathor probably wants us to read `unsafe extern`: https://github.com/rust-lang/rfcs/pull/3439 tmandry: +1 Niko: I'd be happy to just read the RFC. We should do that more often. RFCs: - [MaybeDangling - #3336](https://github.com/rust-lang/rfcs/pull/3336) - [Add `bf16`, `f64f64` and `f80` types - #3456](https://github.com/rust-lang/rfcs/pull/3456) - [UnsafeAliased - #3467](https://github.com/rust-lang/rfcs/pull/3467) - [Inherent trait impls - #2375](https://github.com/rust-lang/rfcs/pull/2375) - [Unsafe extern blocks - #3439](https://github.com/rust-lang/rfcs/pull/3439) - [Unified string literals - #3475](https://github.com/rust-lang/rfcs/pull/3475) - [Placement by return - #2884](https://github.com/rust-lang/rfcs/pull/2884) - [Unsafe lifetime - #3199](https://github.com/rust-lang/rfcs/pull/3199) - [Aligned trait - #3319](https://github.com/rust-lang/rfcs/pull/3319) - [Code string literals - #3450](https://github.com/rust-lang/rfcs/pull/3450) - [Implementable trait aliases - #3437](https://github.com/rust-lang/rfcs/pull/3437) - [Add `f16` and `f128` float types](https://github.com/rust-lang/rfcs/pull/3453) Consensus: We'll use the meetings this month to read RFCs. We'll discuss [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rfc.20reads/near/389488227) to finish scheduling. ## Notes from discussion on ABI https://github.com/rust-lang/rust/pull/115476 TC: The context for this coming up was this discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/layout.20guarantees.20for.20option-like.20enums/near/388318928 Which raised the question of whether the question discussed in RalfJ's PR was already guaranteed in Rust, e.g. with respect to the types discussed in this RFC: https://rust-lang.github.io/rfcs/3391-result_ffi_guarantees.html Niko: I'm in favor of documenting this, and documenting this sort of thing in general. pnkfelix: There's not a subtyping relationship between `C` and `C-unwind`. Niko: Correct. tmandry: We've closed the door to a function pointer that carries data in `#[repr(Rust)]`, for FFI? TC: Looks good to me. Everyone in favor? Josh: +1. But it'd be nice to not duplicate this between `core` and `std`. pnkfelix: But we shouldn't block this on that. That's a problem for us in general. Niko: That's probably not a lang-team concern, but it's a valid one. pnkfelix: +1 on landing this. It'd be nice if it had some examples of things that are and are not ABI-compatible. Josh: There are examples there about things that are not. tmandry: +1. Box checked. (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