--- title: Planning meeting 2024-10-02 tags: ["T-lang", "planning-meeting", "minutes"] date: 2024-10-02 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Planning.20meeting.202024-10-02 url: https://hackmd.io/knFyIAizSjm8NPXIQFKiOQ --- # T-lang planning meeting agenda - Meeting date: 2024-10-02 ## Attendance - People: TC, nikomatsakis, Josh, tmandry, scottmcm (for part) eholk, yosh ## Meeting roles - Minutes, driver: TC ## Proposed meetings - "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) - "Design meeting: Let chains, guard patterns, and `is`; oh my!" [#278](https://github.com/rust-lang/lang-team/issues/278) - "Discuss agendas for Rust All Hands" [#279](https://github.com/rust-lang/lang-team/issues/279) - "Alternative model for pattern matching and match ergonomics" [#280](https://github.com/rust-lang/lang-team/issues/280) - "Design meeting: Async iteration (part 1)" [#284](https://github.com/rust-lang/lang-team/issues/284) - "Meeting proposal: rename "object safety" to "dyn compatibility"" [#286](https://github.com/rust-lang/lang-team/issues/286) - "Design meeting: Effect-Generic Trait Declarations" [#287](https://github.com/rust-lang/lang-team/issues/287) - Spec discussion Please update these in https://github.com/orgs/rust-lang/projects/31/views/7. ### Short list - Transformer syntactic design pattern - "Design meeting: Default field values" [#291](https://github.com/rust-lang/lang-team/issues/291) - "Design meeting: Trait method impl restrictions" [#288](https://github.com/rust-lang/lang-team/issues/288) - Concern resolution - Ergonomic ref counting - Naming `derive(SmartPtr)` - Async closures omnibus - Async drop experiments ## Meeting schedule - October 2: Planning. - Match ergonomics for Rust 2024. - `derive(SmartPtr)` bikeshed. - Supertrait item shadowing v2. - October 9: Josh out - Default field values - October 16: Josh out, Tyler out - Extended triage - October 23: - Concern resolution (or omnibus if needed) - October 30: - Spec discussion (if needed) ## Match ergonomics TC: Here's the document to reference: https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q Specifically: https://hackmd.io/zUqs2ISNQ0Wrnxsa9nhD0Q#RFC-3627-nano ```rust // Violates Rule 1C let [ref x] = &mut [T]; // x: &T // Compliant with Rule 1C let &mut [ref x] = &mut [T]; // x: &T ``` ```rust let [&x] = &[&T]; // x: T (today) let [&x] = &[&T]; // x: &T (Rule 2) let [&x] = &[&T]; //~ ERROR // Migration let &[&x] = &[&T]; ``` ```rust let [&x] = &mut [&x]; let [&x] = &[&mut x]; ``` tmandry: Sounds reasonable. NM: +1. I'd like us to do this and then do a fast-follow with more. ## `derive(SmartPtr)` https://github.com/rust-lang/rust/issues/129104 NM: It's a bit of C++ jargon. It's about being able to work nicely with `dyn`. I've proposed FCP on the name: ```rust #[derive(DynCapablePointer)] ``` TC: Didn't we decide that `Ptr` made more sense in an earlier meeting? NM: I'd be OK with that. TM: `DynamicReceiver`? NM: It then doesn't capture the other half, that you can also store a reference to slice or a reference to a `dyn`. I think that `#[derive(DynReceiver)]` is pretty good also. TC: Did we decide whether this would automatically derive `Receiver`? I know this didn't originally. If it does, it would lend some weight to `DynReceiver`, otherwise that would be weird. NM: I'll check with Alice. TC: We did just decide to call traits "dyn compatible" (rather than "capable"). But maybe this is different. NM: It is pretty close... it's a pointer that can be used in a dyn compatible trait. NM: Alice points out that [it does not provide receiver](https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html#receiver-and-deref-implementations), to leave room for things like raw pointers which do not act as smart pointers but still want to be able to coerce to hold a ref to dyn. This is another reason why I don't think this should be called "derive(SmartPointer)", given that it is designed to be used with things that are not smart pointers (e.g., raw pointers). (smart pointers meaning, to me, things that act like Box/Rc/Arc and can be used in lieu of a reference). * `#[derive(DynCompatiblePtr)]` * `#[derive(UnsizeCompatiblePtr)]` * `#[derive(DynPtr)]` * `#[derive(DynablePtr)]` * `#[derive(UnsizePtr)]` * `#[derive(UnsizablePtr)]` -- ambiguous what is being unsized, not a word that we use elsewhere * `#[derive(WidePtr)]` * `#[derive(CanUnsizePtr)]` * `#[derive(CanUnsize)]` -- Confusing because `Unsize` means "can unsize", this is "can unsize pointer" * `#[derive(UnsizePtr)]` * `#[derive(UnsizePointee)]` * `#[derive(CanUnsizePointee)]` -- and rename `Unsize` to `CanUnsize` * `#[derive(PointeeMcPointface)]` TC: I like `DynPtr` a lot. (Later: but I've reconsidered.) NM: +1, it's short. Josh: It should be clear that it's something that can be made into a dyn pointer rather than being one itself. TC: Then `DynablePtr`. Good by me too. NM: +1. TC: I'm warming up to `UnsizablePtr`. Criteria for Dynable/Unsizable * Pro -- short-ish * Pro -- conveys (vaguely) that this is not declaring the struct to be a ptr-to-dyn but rather a pointer that can become a ptr-to-dyn * Pro -- Unambiguous * Pro -- conveys that it can be used as the receiver of a trait * Con -- doesn't really capture slicing (but that's ok) * alternative we considered was `derive(UnsizeablePtr)` * some have expressed concerns about `Unsize` but that was in a context where it replaced `?Sized`; this usage is different, in that it really means specifically *unsized types* like `dyn` and `[]` * And `Unsizable` is ambiguous: is it a pointer that can be unsize-d, or a pointer that is incapable of being sized? Is it (unsize)-able, or un-(sizable)? * Niko notes: is dynable really so different? you could interpret it as the pointer itself becoming a `dyn Value`, not a pointer to a `dyn Value` * Two ways of spelling Josh: `UnsizeCompatiblePtr` seems OK. (Further discussion that started leaning away from `dyn` and toward `unsize` in some form...) (...The meeting ended and everyone but Josh, Alice, and TC dropped.) (Further discussion...) TC: Josh, Alice, and I ended up landing on and being happy with `derive(UnsizePointee)` for the reasons described here: https://github.com/rust-lang/rust/issues/129104#issuecomment-2389807803 ## 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 ### "Proposal: Remove `i128`/`u128` from the `improper_ctypes` lint" lang-team#255 **Link:** https://github.com/rust-lang/lang-team/issues/255 ### "Lang discussion: Item-level `const {}` blocks, and `const { assert!(...) }`" lang-team#251 **Link:** https://github.com/rust-lang/lang-team/issues/251 ### "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 ### "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 ### "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 ### "Update hackmd link to a public link" lang-team#258 **Link:** https://github.com/rust-lang/lang-team/pull/258 ### "Adding a link to "how to add a feature gate" in the experimenting how-to" lang-team#267 **Link:** https://github.com/rust-lang/lang-team/pull/267 ### "Design meeting: Let chains, guard patterns, and `is`; oh my!" lang-team#278 **Link:** https://github.com/rust-lang/lang-team/issues/278 ### "Discuss agendas for Rust All Hands" lang-team#279 **Link:** https://github.com/rust-lang/lang-team/issues/279 ### "Alternative model for pattern matching and match ergonomics" lang-team#280 **Link:** https://github.com/rust-lang/lang-team/issues/280 ### "Design meeting: Async iteration (part 1)" lang-team#284 **Link:** https://github.com/rust-lang/lang-team/issues/284 ### "Planning meeting: 2024-09-04" lang-team#285 **Link:** https://github.com/rust-lang/lang-team/issues/285 ### "Meeting proposal: rename "object safety" to "dyn compatibility"" lang-team#286 **Link:** https://github.com/rust-lang/lang-team/issues/286 ### "Design meeting: Effect-Generic Trait Declarations" lang-team#287 **Link:** https://github.com/rust-lang/lang-team/issues/287 ### "Design meeting: Trait method impl restrictions" lang-team#288 **Link:** https://github.com/rust-lang/lang-team/issues/288 ### "Design meeting: Profiles" lang-team#289 **Link:** https://github.com/rust-lang/lang-team/issues/289 ### "text describing how other teams are enabled to make decisions." lang-team#290 **Link:** https://github.com/rust-lang/lang-team/pull/290 ### "Design meeting: Default field values" lang-team#291 **Link:** https://github.com/rust-lang/lang-team/issues/291