Planning meeting 2024-01-03

--- title: Planning meeting 2024-01-03 tags: ["T-lang", "planning-meeting", "minutes"] date: 2024-01-03 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Planning.20meeting.202024-01-03 url: https://hackmd.io/wD9I9u7NTbW2zBvpuYLh4g --- # T-lang planning meeting agenda - Meeting date: 2024-01-03 ## Attendance - People: TC, pnkfelix, NM, JT, tmandry, CE ## Meeting roles - Minutes, driver: TC ## Proposed meetings - "Design meeting: Rust for Linux" [#240](https://github.com/rust-lang/lang-team/issues/240) - "We need to settle the behaviour of floating-point in `const`" [#222](https://github.com/rust-lang/lang-team/issues/222) - "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" [#193](https://github.com/rust-lang/lang-team/issues/193) - "Nail down cargo-script syntax proposal" [#232](https://github.com/rust-lang/lang-team/issues/232) - "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) - "Bounds for RPIT/RPITIT/async fn" [#246](https://github.com/rust-lang/lang-team/issues/246) Please update these in https://github.com/orgs/rust-lang/projects/31/views/7. ## Availability - 10th: nikomatsakis unavailable. - 17th: tmandry may or may not be available. - 24th: - 31th: ## Scheduling - 10th: Edition triage/planning: [Project board](https://github.com/orgs/rust-lang/projects/43/views/2) - 17th: Postfix macros (RFC 2442) - 24th: RTN [#246](https://github.com/rust-lang/lang-team/issues/246) - 31th: RFL ### RTN tmandry: We just stabilized RPITIT. We might want one on RTN. NM: Yes. We should have a meeting on how we're going to solve `Send` bounds, and that still seems the most promising way. TC: We had a design meeting on this some months ago. How would we want to frame the changes since then? NM: I'd probably frame this in terms of how we can do an MVP. TC: Someone proposed on Zulip inferred associated types. Swift has something like this. This is actually an RTN counter-proposal in its effect. We should probably discuss this as an alternative. JT: Similarly, we should talk about the option of setting the option of the available bounds at the definition site rather than the use site. NM/tmandry/TC/JT: Agreed, we should discuss all these things. TC: Let's open a thread to collaborate on the document. ## GATs JT: Anything we can do to unblock GAT limitations? CE: It's all about the new trait solver. So unfortunately not. ## General edition triage tmandry: We should do more triage about the edition. TC: If we cut the edition today, there wouldn't be anything there. Everything has dependencies. We'll need to track that carefully. tmandry/NM: Indeed. NM: We'll have to find owners for this. tmandry: Let's talk through the project board in the meeting. ## "Nail down cargo-script syntax proposal" **Link:** https://github.com/rust-lang/lang-team/issues/232 JT: We've moved away from the triple-backtick proposal. It's too difficult to incorporate in markdown documents. Ed Page is updating the RFC with this and the other feedback received. (Discussion about how to proceed on this...) *Consensus*: Let's try to resolve this async. TC (post-meeting): Ed Page has an experimental implementation up at: https://github.com/rust-lang/cargo/pull/13241 It implements `---`-delimited and `###`-delimited blocks so that we can try them out and get a feel for them in use. Ed says that he's still weighing the concerns around `##`-prefixed lines and how an implementation for that would look. ## Pattern types JT: Might we be able to have a document for pattern types by the 17th? I might ping Oli about this. ## RFC read: bitfields support https://github.com/rust-lang/rfcs/pull/3113 ## RFC read: field projection https://github.com/rust-lang/rfcs/pull/3318 NM: This could be too open-ended. This may need heads-down work. I still like my closures idea. ## Move only types JT: I might be up for writing an RFC for a constrained version of this. ## Postfix macros JT: Perhaps we could discuss: https://github.com/rust-lang/rfcs/pull/2442 And if we have time remaining: https://github.com/rust-lang/rfcs/pull/3295 all: Interesting! JT: I'll write up a design document that covers the open items since this was last discussed. ## RFC read: UnsafeAliased / UnsafePinned https://github.com/rust-lang/rfcs/pull/3467 ## "Design meeting: Rust for Linux" **Link:** https://github.com/rust-lang/lang-team/issues/240 TC: There was some excitement about scheduling this when we discussed it last month. tgross proposes: > We would like an opportunity to discuss what has been going well and what has been difficult with RfL. There are two recently relevant topics that would be good to discuss: > > * Bitfields have been somewhat of a pain point. Are there thoughts on official support? [Add bitfields support rfcs#3113](https://github.com/rust-lang/rfcs/pull/3113)? > * Field projection, which improves pin ergonomics (likely also some of the bitfield pain points). [RFC: Field projection rfcs#3318](https://github.com/rust-lang/rfcs/pull/3318) > > It would be nice to just get the general feel of what the team thinks here, we do not need to plan for in-depth discussion. > > I think that a large portion of the meeting will likely just be introductions and figuring out what kind of communication we would like to have going forward. > > If time allows, we can go through the wanted features lists and spend 1-2 minutes per topic getting a pulse check (whether the Rust team would like / is open to / is against each item) so we know how best to proceed with workarounds vs. in-tree work. > > # Background reading > > * A list of new features for RfL [Rust wanted features Rust-for-Linux/linux#354](https://github.com/Rust-for-Linux/linux/issues/354) > * A list of unstable features we use or would like to use [Rust unstable features needed for the kernel Rust-for-Linux/linux#2](https://github.com/Rust-for-Linux/linux/issues/2) > * Some of the complications of safely accessing bitfields in extern structs [bitfields raw pointer accessors rust-bindgen#2674](https://github.com/rust-lang/rust-bindgen/issues/2674) TC: I've been talking with Trevor and others from RFL, and this design meeting proposal originated from those discussions. TC: This has some time pressure, as Rust is getting significant uptake within the kernel, but as long as RFL lives on unstable, the perception of the Linux kernel community is that Rust is an unstable language, because we break their code every 6 weeks. JT: Thought on bitfields: the BDFL of the Nim language [mentioned](https://github.com/rust-lang/rfcs/pull/3470#issuecomment-1676109036) an interest in interoperability with their bitfields, and it'd be nice to talk about what we'd get from "native" bitfield support. tmandry: I'm left wondering, what are the areas with the largest amount of pain? TC: Here's their issue with the the list unstable features they need: https://github.com/Rust-for-Linux/linux/issues/2 They have the issues categorized by priority. NM: A good outcome for the meeting would be identifying goals that might be important for the year. tmandry: +1. tmandry: Some of the things they're using may not be possible to stabilize though. TC: What's important here are their use cases. It's not about stabilizing exactly what they're using. If they're using some nightly feature, it likely represents a use case that we should think about and develop some solution for, even if it's not what we have in nightly today. tmandry: I like that framing. TC: Part of what's happening here is that RFL is writing their own abstractions and -- essentially -- workarounds for missing language features. That's great in that it lets them move faster. But it's not great to the extent that it prevents feedback to us. In talking with some people at Microsoft, it seems their teams want many of these same features. So we should think about this holistically. tmandry/NM: +1. JT: It'd be good to have an async discussion early on this. TC: I'll open or bump a Zulip thread for this. ## "We need to settle the behaviour of floating-point in `const`" **Link:** https://github.com/rust-lang/lang-team/issues/222 TC: scottmcm proposes: > We need to settle what `match`ing means -- is it bitwise structural on the non-padding? is it `PartialEq`? -- and in particular what are the implications of that for floats (with NAN and ±0 and ...) > > Per niko this has been an issue since Rust 0.8; it would be really nice to resolve it 🙂 > > # Background reading > > [rust-lang/rust#116098](https://github.com/rust-lang/rust/pull/116098) [rust-lang/rust#116284](https://github.com/rust-lang/rust/pull/116284) TC: RalfJ noted: > We didn't get to this when meeting for [#220](https://github.com/rust-lang/lang-team/issues/220) so this might still warrant a separate meeting. ## "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" **Link:** https://github.com/rust-lang/lang-team/issues/193 TC: pnkfelix proposes this one for us: > There's a future-incompat lint, `proc_macro_derive_resolution_fallback` ([rust-lang/rust#83583](https://github.com/rust-lang/rust/issues/83583)), which seemed like a slam dunk, but moving it to a hard error had unexpected repercussions due to a slight expressiveness limitation, "Paths involving 'super' don't work from within a function" ([rust-lang/rust#64079](https://github.com/rust-lang/rust/issues/64079)). > > I want to meet to survey the solutions (I believe two have been proposed and I want to put forward at least a third) and evaluate whether to push aggressively to re-hard-error `proc_macro_derive_resolution_fallback` or if we want to make some language change first to better serve authors of derive macros. ## "Design meeting: Rust issues encountered by new Rust users in the Bevy project" **Link:** https://github.com/rust-lang/lang-team/issues/229 TC: Josh proposes this one for us: > The Bevy project gets a particularly large number of new Rust users, who are learning Rust in order to use Bevy. Bevy also gets people programming for the _first_ time, and trying to learn Rust as a first language. They collected a pile of feedback on things those new Rust users find challenging. We should arrange a meeting for @alice-i-cecile and other Bevy leaders to bring some of those issues to us. > > We should try to avoid delving _too_ deep into solution space on any one issue, and should try to hear out the breadth of issues, with particular attention to any that we aren't already thinking about. ## 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.