Triage meeting 2026-03-11

--- title: Triage meeting 2026-03-11 tags: ["T-lang", "triage-meeting", "minutes"] date: 2026-03-11 discussion: https://rust-lang.zulipchat.com/#narrow/channel/410673-t-lang.2Fmeetings/topic/Triage.20meeting.202026-03-11/ url: https://hackmd.io/FZR0FoQ4RkC4G3i-dKiyzg --- # T-lang meeting agenda - Meeting date: 2026-03-11 ## Attendance - People: TC, Niko, Josh, Tyler, Jack, zachs18, Benno Lossin, Nurzhan, Tomas, Nadri ## Meeting roles - Driver: TC - Minutes: Nurzhan, Tomas ## Scheduled meetings None. Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7. ## Announcements or custom items (Meeting attendees, feel free to add items here!) ### Guest attendee items TC: For any guests who are present, please note in this section if you're attending for the purposes of any items on (or off) the agenda in particular. ### Moving right along TC: As we've been doing recently, due to the impressive backlog, I'm going to push the pace a bit. If it's ever too fast or you need a moment before we move on, please raise a hand and we'll pause. ### Design meeting at 12:30 EST / 09:30 PST / 17:30 CET TC: Remember that we have a design/planning meeting that starts half an hour after this call ends. ### Next meeting with RfL We're next meeting with RfL on 2026-03-11 to review the status of RfL project goals. https://github.com/rust-lang/rfcs/pull/3614 ## Nominated RFCs, PRs, and issues ### "Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32`" rust#139087 **Link:** https://github.com/rust-lang/rust/pull/139087 TC: This got [renominated](https://github.com/rust-lang/rust/pull/139087#issuecomment-4014444604) by folkertdev after we discussed this in the past. Is there something we can do to unblock the stabilization of f16? Jack: I think we can stabilize without `impl From<f32> for f32` ?: Is the From impl controversial? Tyler: I mean the fallback behavior. Jack: ?? I'm concerned that if we land this, we'll have to keep it forever. Niko: What's the amount of breakage? Josh: We have a crater run somewhere, but IIRC it was a lot. More than we can deal with. Tyler: Is the concern the specific impl, or the general approach? Jack: The concern is sort of both. I think any extra fallback here would be concerning. Tyler: We can't? add this without breakage. I'm fine stabilizing without the impl, but eventually we'll have to add the impl though. Jack: I don't think we have to add the impl. It's not great, but not unusable without it. Tyler: Yes, it would be unsatisfying to leave it in this state. TC: I found [the crater report](https://github.com/rust-lang/rust/pull/122470#issuecomment-2062637462) after adding it. It's on a merged PR from 2024. Around 1700 regressed. This is allowed breakage, but wouldn't be the first time we had a breakage of >1000 crates. This is tricky for us. Josh: I tend to agree with Tyler's point. He doesn't seem to oppose stabilization, he wants a path to getting to the satisfying solution. If we feel like we'll never get there because types don't think we'll find a solution, I'd be concerned about shipping the type. Jack: I'd say the solution here is literal numeric types. That's right from the type side to not fallback. The issue is that it's far, but also on the horizon. We shouldn't expect this in the next year. Is that enough to say we have some potential solution in mind? If we get to a point where we've exhausted the other solution, and we still want this impl, we can always add the impl later. We'll only want that if we decide that we're fine with the maintenance and there's no better alternative. Nadri: can we have a smoother transition to adding the impl? 1) adding an impl over an edition if we can; 2) warning if the current behavior is triggered by any crate. even though it might be hard from types side Tyler: Sounds like this is a types team discussion that needs to happen. TC: Can you be more specific on that? Tyler: Types team discussion needs to happen on what's the likely path to getting this impl if we're going to avoid the breakage. I'm hearing concerns, but without the team having discu. Jack: This is not a high priority for t-types right now. I'll need to gather the team for this this quarter. The decision for lang is "could we stabilize f16 without this impl? If so, there may be a path to this impl in the future". I think there is, but it's not soon. Or does lang not want to stabilize f16 without the impl, in which case it's blocked on t-types? Niko: Like Nadri said, a satisfying solution would be a warning discouraging people from relying on inference... This is a good example of something that's not a types priority that we still need to prioritize because it's a Project priority. We have this type. I also thought about the edition. Josh: 1) Jack, earlier you said that one path would be literal types, which was far off. Do you think we're likely to successfully get there, or is this more uncertain? 2) Are there blockers to that? Prerequisites? Would someone be able to work on it given this is on their priority list? Jack: I don't think there's blockers other than design. The only thing required is time, unless someone steps up and wants to do this, I don't see anyone having time to do this now. That's why it feels far off. Josh: Are you talking about time for impl or time for design and running it by types, or both? Jack: I think the impl is straightforward; most of it should be design. I don't think it will embed itself into the type system deeply. TC: I don't want to block this on any new feature or on t-types. I think we should be able to do this using our existing mechanisms. I want to see an updated crater report and a proposal on what we can do with lints to move people off of reliance on inference behavior. We would be able to land this impl then with more certainty. That would allow us to land f16 without it being blocked on implementation of something else. Jack:I agree. We should pronably not block stabilizing on some impl that has concerns or a future impl we don't know yet. I think al int is doable. I also want to propose an option where we land the impl on nightly and not stabilize, getting people who are on nightly start making the changes. Niko: Do we have nightly-only impls? ?? config Jack: My thought is just "revert on beta". Niko: Josh: TC, you've been describing a couple of paths. I've heard enough here that I'm comfortable with shipping the type without worrying about the impls yet. I'd be happy with unblocking people from writing their impls on f16 in the ecosystem. I would be against linting against folks using float literals. If we could do a narrowly scoped thing in an attempt to discourage people from relying on ?? impl rule, that would be more reasonable. ?? but there was a proposal to lint on `impl T for T`. If we can get a lin on that narrow thing, that would be fine. TC: To clarify, I'm proposing one path -- linting on this and accepting the breakage after sitting on this for a while. Then we land f16 now on the basis of having an unconditional plan for how we'll land the impl. Niko: +1 to TC's plan, myself. Tyler: I like that plan, and Nadri's suggestion to use a lint there. Because we have the one-impl rule, whether in std or user code, we need a way to add new impls without breaking existing code. There should be a mechanism for that, whether it's a way to control fallback behavior or something else. We don't have to solve it right now, but I want to see it eventually. Josh: Same outcome, different rationale. I'm fine with signing off on the stabilization of f16 and a narrowly scoped lint that warns on the use of fallback together with the one instance rule. But I wouldn't precommit to landing the breaking impl. TC: If we FCW this it'll cause people to migrate, but our crater runs will never be clean because of unmaintained crates... Josh: I'm not referring to the case of a handful of crates that stay unmaintained. Sometimes FCW lead to other conversations where people have other usecases. It will be an ongoing, evolving conversation. Niko: I don't think we ever pre-commit to anything. I'm not sure what procedural difference we're talking about here. If you want to stop us from adding an impl, you'd have to add another FCP to stop us. We'll add FCW which declares our intent. If we find ways without the breakage that's preferable. We hope to do it in a certain span of time. Josh: depends what the pan of time is. If we get to a point where in 6 months we haven't found anything, we can look to landing it. Anyway, +1 for shipping f16 and +1 for finding a narrowly scoped lint. Jack: Do we want to lock shipping f16 on a FCW lint? Can we ship f16 and later add the lint? Niko: I think we can ship them independently. Josh: Agreed Tyler: It would be cleaner to land them together. If the lint turns out difficult, I'd not block. TC: I don't know if we need to decide this. I think the next point is asking for the FCW. Jack: We want to lint, but if people want to start stabilizing, should we say someone should start working on the lint or start stabilizing? Are they starting with stabilization or the lint? TC: E.g., "We're interested in unblocking the stabilization of f16. To do that, we're curious about adding a lint against this fallback behavior. Etc." Jack: That's stronger than what people are saying. People are saying "it's okay to stabilize without the lint". TC: We can just ask what the plausibility of getting a lint is. We might have the lint next week. Josh: We're spending lots of time on something we mostly agree on. Should we continue async? ### "`DerefMut` auto-deref error for `union` fields sometimes doesn't trigger" rust#141621 **Link:** https://github.com/rust-lang/rust/issues/141621 TC: We had talked about it and asked Ralf to propose something to us. He came back hoping we'd propose something to him. He supports what Scott said: > My biggest thought here is trying to apply my draft heuristic of "would it be more work to define the behaviour or define the error?". It seems to me like if we just deleted this error from the spec we wouldn't need to replace it with anything, as all the existing rules for what it means to use a place as a receiver and how that's handled is defined, it's just a footgun in this context. > Which puts my inclination here to be "well, maybe it should be a deny-by-default lint then", which gives us freedom to tweak the details of exactly what it does or doesn't catch without needing full FCP+FCW+Break+Etc stuff every time. Josh: The proposal seems to be swtich this to a lint. TC: Yes. I nominated this so we look at it and confirm we're happy doing what Scott proposed. Josh: Seems like we should do this. I'm happy Ralf didn't come up with some soundness issues. I'd be inclined to say let's do an FCP to switch this to a lint instead of a hard error. Tyler: Ship it. TC: +1 here too. Josh: I'll start an FCP. ### "Do not deduplicate captured args while expanding `format_args!`" rust#149926 **Link:** https://github.com/rust-lang/rust/pull/149926 Niko: I gave this some thought. I still am unconvinced that we're making the right call. Not worth discussing now, I commit to having a comment by next week. Scott: Could we steal some other behavior for this? Closure captures have a similar behavior to what we want. Maybe we could have the macro desugar to a closure capture. Then we can use rules that are smart and we want for other reasons. Niko: I think Josh wants to pitch something similar for `self.foo!` macros Josh: Yes, I did propose reusing that desugaring for `self`. Not sure if it's the right one *here*, though. Nadri: If taken literally, this might not solve the thing we care about. The motivating example is using a const with a drop impl and that would be duplicated with closure capture rules too. Josh: Exactly, it would still have the current semantics, not the proposed ones, which wouldn't be ideal. Tyler: If we use the closure capture rules, it doesn't solve arbitrary expressions inside of braces. There's no closure capture rule that lets you express: ``` println!("{foo()} {foo()}"); ``` TC: Right, and like Nadri pointed out, it doesn't solve const either. Scott: Pondering if instead of storing references directly in `FormatArgs` storing the `impl FnOnce() -> (&T, &Y)` or something. TC: Niko and I have a call later; maybe we'll try to convince each other. Josh: TC, if you end up scheduling something for ~~that~~, I'd love to join. ### "privacy: Fix type privacy holes when it doesn't cause too much breakage" rust#152543 **Link:** https://github.com/rust-lang/rust/pull/152543 TC: This is petrochenkov; we FCPd this before. When we originally looked at this, there was one commit affecting RPITIT -- where RPITIT was inconsistent with RPIT. But it's inconsistent with bare associated types too, so he added another commit. But that commit caused breakage. So now we're back to the original commit just affecting RPITIT. I proposed FCP merge on the basis that we should close the asymmetry with RPIT. On the other hand, nobody can demonstrate these private bounds causing actual unsoundness. It's a bit conservative -- we're clawing back what we can; we could relax it later. If we actually needed this space for the soundness of a future feature, we'd have to close this for the associated types as well. Josh: This is what we're proposing for FCP: ```rust pub trait PubTrait { fn foo1() -> impl PrivTrait; // error now fn foo2() -> impl PubTrait<PrivType>; // error now type A1: PrivTrait; // not error, too much breakage (but reports `private_bounds` lint) type A2: PubTrait<PrivType>; // not error, too much breakage (but reports `private_bounds` lint) } ``` (https://github.com/rust-lang/rust/pull/152543#issuecomment-3996781526) Josh: How much breakage is there? TC: A dozen or two of crates. Josh: Were issues filed and they didn't respond? TC: I don't know. Niko: I continue to dislike this whole direction, but I'll check the box. Something still feels weird. TC: I agree. I think this is space-saving while we work out a more satisfying model. Scott: I'm not convinced private types on associated bounds is a problem at all, but RPITIT and RPIT symmetry seem reasonable, so happy to FCP that much. AFAIK from C# you can have internal interfaces on public types. Having an internal interface within a sealed public trait having private associated types is entirely reasonable. ### "Lint on (nearly) all `{integer}`/`{float}` fallback" rust#152589 **Link:** https://github.com/rust-lang/rust/issues/152589 TC: Scott, you filed this a while ago and set a high drag. I lowered the drag because this is a vibe check. Scott: I put in 3 because it didn't feel time critical. In real code I'd like to be warned on i32 and f64. I want to get a vibe if people vs. if this would be a plausible reason to lint on it. TC: My vibe is aligned with yours. I don't want to rely on the fallback in production code. When doing a crater run on this, I predict that we'll find that while most production code doesn't rely on this that tests do. Scott: This makes sense. Josh: You're not talking about fallback for writing a literal that could be one of multiple types but turns out to be one of them — you're talking about the case where there's no obvious type and we fall back to i32/f64? Scott: I'm talking about: I wrote a literal, didn't put a suffix and after doing trait solving there was nothing to force it to become a particular type. Josh: You have an Add op implemented through a trait. You could have Add impls for adding different integer types to your bignum, and then write `my_bignum + 1`, that would rely on fallback, right? Scott: That would depend on the number of impls. If you only write one, the reason `this + 1` works is because inference ??. I wouldn't want every `+1` to fail. Niko: Long ago, we removed integer fallback, which required a few small edits in the compiler. We didn't have crater then. I suspect it'd be worse now. I still don't love to fallback. Not sure how we'd lint it. I'd like to see what crater looks like for tests. Scott: Tests is a good point. Josh: I don't want this to be warn or deny by default. I predict that the breakage would be obscene. TC: This is a good case for an allow-by-default lint in *rustc*. Tyler: Makes sense as an allow-by-default lint. I'd want to turn it on in my own code and see. I'm not convinced we want warn-by-default. Josh: Scott's example `for _ in 0..100` would presumably rely on fallback, assuming you're not constraining the index otherwise. Scott: I'll write about the concerns about tests and the big integer case, and about a potential interest in seeing what it could look like. Jack: Jack You can have a more advanced lint. Only lint on fallback that's observed. Where you wouldn't lint on underscore for 0..100 but lint on other things. TC: We did something similar for the never fallback lints. ### "[type layout] usize and isize have the same size and alignment" reference#2200 **Link:** https://github.com/rust-lang/reference/pull/2200 TC: This is a new language guarantee. We got 3 checkboxes, which put it into FCP. It's guaranteeing that `usize` and `isize` have the same size and alignment. Nadri: We seem to have confirmation from the LLVM and opsem ppl that even LLVM is not insane enough to have sign-dependent size/alignment TC: I'd originally marked this as easy decision, but... one never knows, so I took the label off. Scott: `i128` and `_BitInt(128)` having different alignment is already annoying Scott: There isn't currently a rule in the Reference about uN and iN having the same alignment. Should we ask them to make a new PR adding that somewhere? TC: Ask them to make the PR and FCP it. --- The triage meeting ended here. --- ## Planning design meetings People (part 2): TC, Niko, tmandry, Nadri, Jack, Tomas, Nurzhan, James Muriuki Driver: TC Minutes: Tomas + Nurzhan The project board: https://github.com/orgs/rust-lang/projects/71/views/1 Tyler: Q1 we're already oversaturated. Let's ratify the list of meetings we want to schedule for the rest of Q1 and Q2, note when people will be out and list people who want to attend specific meeting, TC and I can schedule offline. TC: Sounds good. We also need someone to have a document ready on that date. Tyler: Field projections: Nadri & Benno you said it'd be ready around the 25th? Nadri: *nods* Tyler: Open enums -- there's an RFC, we need a design doc though. Tyler: Sized hierarchy -- Niko how are you feeling on that as a champion? Will we have an RFC by end of March? Niko: I think so, I'll check with lqd and David. They seemed to be making progress. TC: Don't we have an RFC on that one? Niko: Needs some refresh / revisions. One question is splitting out the const trait part and focus on the hierarchy. What's the deadline? TC: There's a subpart of the sized hierarchy that might need its own design meeting: treatment of the bounds and how transitive the bounds relaxation should be, whether we need syntax for it, etc. It seems we might want to carve that part out separately. Josh: That is a critical part of the design, we should cover it. But I'd suggest we don't need a separate design meeting -- this seems like 90% of the problem of implementing the sized hierarchy. Sized vs DynSized and all the question-mark traits and how they flow through and how we set the bounds, that's kind of the entire design. The rest, not trying to oversimplify, seems like us saying "yes, we want to use this and implement this feature, let's do it". Niko: There's some bikeshedding on the naming of the traits. There's how you indicate and propagate these limited defaults TC raised. And how the transition and backwards incompatibility going to be navigated. They're distinct. The names one is pretty simple. But the other two might merit their own meeting. Maybe we don't even need the transition plan. Josh: How much is the transition plan distinct from how these bounds flow through? They seem closely related to me. Niko: I think they're different. The transition is about associated types on traits and cases where if you do a naive transition the user experience will be worse. Josh: Let's say that we schedule one design meeting, prioritise the trait hierarchy, how it flows and how we set the bounds. If we have space we can continue and if not we'll have to schedule the design meeting. Niko: Should we say next two weeks for both? It'b be helpful to know up-front how to scope our documents. Josh: I didn't realise you were talking about doing the next two weeks. In that case, let's schedule them. Niko: That's what I'm saying. Josh: Let's do it. Tyler: Are we ready to talk about the transition? Someone's working on implementing it in the compiler. Don't we need that experience for that discussion? Niko: I feel there were values and statements worth deciding upfront. If we're aligned on those, we can trust other people to drive it. Tyler: Then I'd push Field projections to April 1st. Niko: Sounds alright but we could also push the transition. Tyler: Depends on who's ready first. Field projections may be ready as early as next week? Niko, what would we review? Niko: Names of the traits and ?? Nadri: *makes doubtful face about the field projections doc being ready next week* Niko: I'll ping them, let's talk over the course of the day. TC: Open enums? Who's working on it, what will we need? Tyler: There's RFC. Last we talked, we agreed on needing a design doc that covers the broader design space. Scott has some concerns aout the RFC and approach. We need to have that discussion. I don't know if we'll get a design doc. Niko: Is it worth having a more abstract discussion? Tyler: Might be. Could be a deep dive or a separate discussion with Scott, you etc. Niko: I was surprised by how much Alice said she wants this. Josh: If you're dealing with Rust and C daily, open enums are really important. Tyler: Let's schedule a meeting between interested parties. Doesn't have to be full design meeting. TC: I'm broadly sympathetic to Scott's points. There may be more lang people we need here. Josh: Many people are saying this is important. Doesn't mean this RFC is leaning in the correct direction. Scott's been thinking a lot about enum direction. I'd trust his judgement in that area. This is a problem we should solve, how should we go about doing that? Tyler: We need to talk about it. Could we do this for 20-30 minutes and have next steps? I don't know. Scott's not here, let's defer for now. TC: Anything else in Q1 that needed attention? Tyler: Don't think so. TC: Q2: reflection and comptime. Tyler: Scott's checking on that. TC: It's going to be oli who writes that doc. I talked with oli about this couple weeks ago. TC: On const traits, that might be mine to write. We need to pick a syntax for this. Oli expressed he and fee1-dead would be happy with any syntax within the parameters we discussed. There's an angle on how we use an edition to phase this. I have a write up that I should polish and then get lang alignment on so we can get that back to Oli. Jack: I probably agree with what you're saying. First step: talk about principles we want. And then discuss solutions and how they fit in the principles. The syntax can be bikesheddy. Might be good to think about aligning the discussion on that. Editions are likely going to be needed to get us where our principles are. TC: That's basically right. This will be a heavy thing in terms of syntactic weight. It's going to be everywhere. It'll change the way Rust looks. The inclination is to lower the syntactic weight on this. And then focus the design on how it looks in the next edition while having a very explicit syntax in this edition. Jack: When we schedule this, we should be clear to talk about the principles we want and discuss those. Josh: Can we please have a strict separation in the document between the design of const traits and the concrete syntax? My impression was "we're mostly done other than the syntax". But I'm now hearing different things on that that make it sound like the semantics aren't nailed down. Can we get the semantics clear orthogonal to syntax? Also, I haven't seen the possibility of syntax that would require a new edition; not in this meeting, but I'd love to see an example of a syntax for const traits that we could unlock via an edition. Tyler: Agreed. TC, sounds like you'll work on the doc? TC: Yes, I need to write it up. Probably sometime in Q2. TC: Partially dyn dyn (AFIDT). Niko, is that your doc? Niko: It is. This is Q2 right? Tyler: Yes. Is that realistic? Niko: I think so. Jack and Santiago and I went over the high-level plan. I have a plan, I'd like to have feedback. This might be worth splitting? There are a few questions I'd like vibe checks and discussions from the team. I could write the doc at any point. Could be next week if I had time to write. Tyler: My goal is to get all the inputs in this meeting so we can schedule them. TC: RFC review for Prepare TAIT + RTN for stabilization. Stabilization blocked on the next trait solver. But there's work we could to on TAIT related to nailing down syntactically how we control the defining scope. It's another document I need to write. I don't think it's going to be controversial. But we'll need a design meeting. TC: Next, stabilizing `f16`. Niko: This is really about the `From` impl. Should we rename? Tyler: I feel we have a plan. Don't think we need a design meeting. TC: Yes. TC: Evolving the standard library API across editions. Josh: Libs API, Amanieu is the point of contact. He'll draft an RFC. We need to ping him to get an RFC / design doc for us to review. TC: Stabilizing const generics. We had couple meetings with Boxy. Niko: Not sure where we're at with that. We're making progress. I'd put it later in Q2. TC: That sounds right. TC: Immobile types and guaranteed destructors. Linear types. Jack: I'm the champion. Theres' no design or RFC or anything. It's on track to get thoughts to get feedback on for Q2. TC: For `Try` trait we need Scott. TC: Do we want to look at Q3? Tyler: Let's just do Q2. The only other inputs we need are vacation dates. Please write them down: TC: The All Hands is in the middle of Q2. Josh: Safe to say none of the video calls will happen that week. But we'll talk in person. Josh: We should write a list of things we want to discuss in the lang meetings there. Tyler: Reminds me I should ping Mara to coordinate the discussions at the All Hands. I'm not going to do that this time, need to let Mara know. Vacation dates: * All hands: May 20 * Tyler: May 6 * Niko: June 3 I might be out, not sure about the rest * Josh: I'll probably be here all the Wednesdays until the end of June * TC: AFAIK I'll be around * Nadri: might miss June 17th, otherwise expecting to be there * Jack: No currently planned days off, but *may* be out for one week in early April. Wednesdays in Q1-Q2: - March 18, 25 - April 1, 8, 15, 22, 29 - May 6, 13, 20, 27 - June 3, 10, 17, 24 - July 1, 8, 15, 22, 29 ## Nominated RFCs, PRs, and issues, part 2 ### "Fields must fit in the type, even for repr(Rust)" reference#2166 **Link:** https://github.com/rust-lang/reference/pull/2166 TC: It's making new guarantees; not sure we'll get through those here. Josh: Last time, people thought this made sense but people expressed desires of having an enum with a single big variant and sticking `!` there. Having a wrapper to construct the type seems reasonable. We need some solution on how to deadhead a branch of an enum -- people want to do that. Nadri: The PR worked around this by saying only constructible fields are relevant, right? It leaves the options you mentioned open. Josh: That would imply if I had enum variant `field, field, !` those would still be reserved. Nadri: It looks like it's trying to leave the door open for that case. Josh: Not clear on that either. It seems to focus on structs mostly. That seems fine but sturcts can be fields of enums and unions. Tyler: We're adding a guarantee but leaving the door open makes sense. Scott: What does 'constructable' mean here? Does it mean something else than 'inhabited'? Josh: This changed. Line 177 spells exactly the case: given an enum with variants, this field is constructible, this one isn't. Given that, this sounds fine to sign off on. Tyler: I FCPd this Scott: Does it define constructible somewhere? Nadri: Yes, line 175: > A field is considered constructible if it is possible to create a value of the type containing the field. Josh: Type `!` is uninhabited, struct containing `!` is uninhabited. Tyler: It's using an enum variant as a type here. Nadri: The wording is weird. Tyler: Agreed. Josh: It's saying it's impossible to construct `E::Value`. Nadri: There's ambiguity. I think it's saying it's possible to create the value using the field. Not the type. Josh: The important property of consructible is line 171: > For any constructible field, its offset plus its size is at most the size of the type. Tyler: 175 is wrong. I'm making a suggestion on how to improve it. Nadri: A field is constructible if... Josh: We should handle the exact wording async. Give the vibe that the broad intention is fine. TC: Let's table this and let people respond. My inclination is to nail this down a bit and then FCP it. Tyler: I'm fine with that. scottmcm: +1 to wanting the exact text for the reference PR before FCPing. ### "Add `homogeneous_try_blocks` RFC" rfcs#3721 **Link:** https://github.com/rust-lang/rfcs/pull/3721 TC: Scott, what do you need from us? Scott: https://github.com/rust-lang/rfcs/pull/3721#issuecomment-3827388553 Scott: What do lang people need before we're ready to move forward. Are you happy with homogeneous? Do you want to include heterogeneus? How to move forward? Josh: Still in favor of the homogenous version of anonymous try. If you want to have a heterogeneous one let's FCP and ship it. I'd check a box on both but I don't want one to delay the other. Tyler: We'll want to want both. Need a way to spell both. Is there an obvious way to extend try syntax to make it explicit? Josh: There's a few. Using an existing keyword but I forgot which one. Scott: we talked about no keyword, talked about `in`. Niko proposed `try as`. Syntax-wise it's easy to extend, just need the keyword. On nightly it's using literally `bikeshed`. Niko: What comes after `bikeshed` keyword? Josh+Scott: A type. `Result`, could be `Residual`. ```rust async -> T { /* does this work? */ } try -> Result<T, ()> { foo()? } ``` Josh: I'd have expected `Result`. Niko: Do we support explicit annotation on async blocks? Might be interesting if we used the arrow operator. Josh: That's the one I thought about. The `try -> type`. It's appealing. Niko: It's the obvious thing I'd expect to work. I think it'd work well. TC: Agreed. TC: What's the behavior when using the underscore in the ascribed type? Scott: It's an inferred type. You either say `try { }` or `try bikeshed TypeHere { }`. If you put an underscore there, the type is inferred. Josh: Try with not type will infer from content, try with `_` infers from context. TC: With the underscore we're creating an inference variable. And for the other? Scott: The `try bikeshed` form uses the contextual type to decide what it's going to produce. Distinction is: when you have .into().into() the non-bikeshed avoids the floating behavior. TC: It'd be interesting to think about how we'd formalize it. Scott: It's currently a desugar to existing features. Tyler: Are we closing off the door to certain try bikeshed syntaxes? I don't think we are. We can move forward with homogeneous and try to figure out the syntax later. Happy to move forward with the RFC as is. Scott: We're closing off that the unannotated form does this particular behaviour. We can stick an arrow and as to do the annotated version. Josh: `try` and `try -> _` wouldn't mean the same thing. That's quirky. But I don't have a better suggestion. Both are distinct concepts, both useful, people will want both. The briefest one should be the ergonomic one. That should be the homogeneous try. I'm happy to defer the heterogeneous one but also fine to FCP the arrow for that. TC: If we have alignment over `->`, maybe it'd be easier to stabilize heterogeneous `try` first. Josh: Thad't defeat part of the purpose. Part of the point of homogeneous try is to solve the underlying problems where using the question mark inside and outside is awkward. Deferring that is going to make it a rocky launch. Niko: This is an editionable thing. Try by itself should let you propagate Results. The only awy to do that we know is the homogeneous try. We should do that. Having an escape hatch that we could change later is fine. It's touching on a really difficult problem. When you have to make an opinionated inference, ?? Tyler: The weirdness is in line with the weirdness people experience today with the type inference. If it's obvious we infer it, if not we require a type annotation. If we find a better way we can do it over an edition. There's no obvious way that's better that occurs to me Josh: Agreed. Editions give me confidence to be able to do this better in the future. We know we need both of these forms. Let's FCP what we have right now. Ask for heterogeneous RFC using the arrow and FCP that. But now, let's FCP the current RFC as proposed with the briefest possible form. TC: I'm hearing the following agreement between us. Homogeneous is what we want without annotation; the heterogeneous one we want probably with the arrow syntax. Separately there's a question on how we approach stabilization. I'd be interested in whether we could stabilize both of these pretty close to each other. That'd be better story. Josh: Agreed. Tyler: I've a bit of doubt about the arrow. Don't hate it but I'm not sure it's the best option. I'd like to talk those through. TC: That makes sense. Josh: I'll propose the FCP and bring in the other thoughts. Tyler: +1. Josh: I'm glad we landed somewhere. We wanted this for a long time. ### "RFC: Allow cfg-attributes on elements of tuple type declarations" rfcs#3532 **Link:** https://github.com/rust-lang/rfcs/pull/3532 TC: The diesel maintainer asked how to move forward; Josh proposed FCP in October. Josh: You have a tuple of types `(T2, T3, T4)` and you want to put a attribute saying that this field doesn't exist given a cfg. Tuples are obvious representations of rows in database adapters. We should add this but this is one more thing in the compiler where it'd need to deal with having a cfg there. If the compiler folks tell us this is painful, we can stop before stabilizing it. Tyler: Making it consistent with struct fields makes sense. Do we allow this for function arguments? TC: I think we do. Josh: I believe we allow this today but I'd have to ccheck. Tyler: Then it slots in nicely, I lean towards accepting it. Agree what you said Josh -- a lot of cases you probably don't want this but in some cases you do. TC: If you look at the Reference-level explanation in the RFC, Josh, do you believe that comprehensively describes the language change? I.e., would I be safe to check a box entirely on that basis, assuming I already buy the general motivation? Josh: If you want to comprehensively understand the definition of the language change, I believe the Reference-level explanation is comprehensively saying that. Tyler: This compiles: ```rust! fn foo( #[cfg(false)] _x: u32, ) {} fn main() { foo( #[cfg(false)] 42 ); } ``` Tyler: We're allowing attributes generally, not just configs. Josh: Right. That's also kind of useful. I could see wanting to have that in macros. Tyler: We allow on structs, I checked we allow cfg attributes on fn parameters. That makes sense. Josh: Ship it. TC: The reference-level explanation makes sense to me. I'll look later and write up a comment. ### "`#![register_{attribute,lint}_tool]`" rfcs#3808 **Link:** https://github.com/rust-lang/rfcs/pull/3808 Tyler: I proposed FCP, it needs one checkbox to go into FCP. I really want the fancy version of this that lets you declare an attribute and provide a macro-rules style checker. Tyler: It allows you to declare attributes and lints declared by tools external to rustc. Model checkers, external lints. The attribute might contain arguments in a lot of cases. In the future I'd like to see a way to give you syntax for the arguments that can integrate with Rust Analyzer. We don't have that but I don't want to block on that. This is blocking a lot of useful tools. Today you have to use `register_lint_tool` that's nightly only. TC: How does it deal with namespacing? Nadri: There's no namespacing in the RFC. That's kind of a feature. If we start being more clever, that's not possible without hooking it into the rust compiler. Right now it's literally a string. Josh: This attribute is providing a form of namespacing itself. You register a tool and you can use that tool name as a namespace. There are proposals on doing more namespacing and tie this e.g. to specific paths to a crate that register a pseudo-macro. I support having that as something people *can* use, and will hopefully enthusiastically adopt in the future, but in the meantime this mechanism is a way of declaring a namespace but there's no way of namespacing the name of the namespace itself. This is largely used by tools that feed it into the command line. E.g. the kernel will register a tool name klint and then use `klint::...` Tyler: You should opt into this tool using your repo. If you're using a tool called `klint` you won't conflict with another tool called `klint`. You control the tool. Nadri: Some of us are trying to use common names. E.g. `verify::` attributes. This is baby steps but sth to consider Josh: This is incremental. What's proposed now will work with sets of cooperating crates, crates within a repo, etc. The future namespacing idea will make this easier to use in the wider ecosystem of more loosely coupled crates, e.g. on crates.io. So I think there will be natural pressure to use it. Tyler: Anyone want to check a box? TC: I'll read it and see about checking a box. ### "`RUSTC_ALLOW_UNSTABLE_<feature>`: a `RUSTC_BOOTSTRAP` alternative" rfcs#3882 **Link:** https://github.com/rust-lang/rfcs/pull/3882 Josh: I have a vibe-check to ask here. One group asks about limiting what we're permitting. Another group is saying that this could be seen as condoning/endorsing `RUSTC_BOOTSTRAP`. We need a judgement call here. Are we making it easire or safer without necessarily condoning it. Tyler: I'm not sure this is lang and there's an existing mechanism: `RUSTC_BOOTSTRAP` plus a `-Z` feature flag. Josh: So defer to a later meeting? TYler: I'm not convinced we should talk about this at all. Josh: This is stalled because nobody's taking responsibility for it. We may wish to at least weigh in. Even if it's just "here's our general vibe and this is on compiler" TC: I think this is lang. We're affected the most by the UX of our stability surface area. Looked at in a certain way, this can be seen as stabilizing our nightly feature flags. That implies needing Lang either to make a decision or to at least be a key stakeholder. I don't think we can slough this one off. Tyler: Maybe I'm just not sure what's proposed is something we should do. TC: Agreed there. ### "Add a note about uninhabited-struct layout optimization" lang-team#346 **Link:** https://github.com/rust-lang/lang-team/pull/346 Scott: Could people take a look and give vibes? It's specifically about structs and not about reference text. Josh: To what extent does that apply if you have an enum variant containing a struct? Nadri: It doesn't. It's consistent with what the Reference is proposing. A different point in the same landscape. Josh: Is the proposal that structs are always made up of constructible fields? Scott: Not necessarily. It's a description for why that's not obvious how to do this so it proposes to leave space for ?? Tyler: Sounds about right. Nadri: There's work around this space, we need it for (MaybeUninit?) Josh: This seems fine, then. TC: Scott, to what degree is this a guarantee the reference already makes for structs being large enough to contain all their fields? Scott: The reference is not taking a position on that. TC: The Reference describes, e.g.: > r[layout.repr.rust.layout] > The only data layout guarantees made by this representation are those required for soundness. These are: > > 1. The offset of a field is divisible by that field's alignment. > 2. The alignment of the type is at least the maximum alignment of its fields. > > r[layout.repr.rust.layout.struct] > For [structs], it is further guaranteed that the fields do not overlap. That is, the fields can be ordered such that the offset plus the size of any field is less than or equal to the offset of the next field in the ordering. The ordering does not have to be the same as the order in which the fields are specified in the declaration of the type. To what degree is this the same as that guarantee? Scott: Can you send it to me? Sounds like we should keep the text to this is why we do this, but we should link to the reference. ### "CMSE calling conventions" rfcs#3884 **Link:** https://github.com/rust-lang/rfcs/pull/3884 ### "`#[expect(unused)]` false-positive `unfulfilled_lint_expectations` warning on implemented but unused traits" rust#152370 **Link:** https://github.com/rust-lang/rust/issues/152370 ### "Allow `UnsafeCell` in shared statics" rust#152540 **Link:** https://github.com/rust-lang/rust/pull/152540 ### "UB inconsistency when derefing a place in a closure" reference#2121 **Link:** https://github.com/rust-lang/reference/issues/2121 ### "Add a FRC about implicit numeric widening" lang-team#356 **Link:** https://github.com/rust-lang/lang-team/pull/356 ### "RFC: cfg_target_version" rfcs#3750 **Link:** https://github.com/rust-lang/rfcs/pull/3750 ### "repr(ordered_fields)" rfcs#3845 **Link:** https://github.com/rust-lang/rfcs/pull/3845 ### "Match guard can both move and static-promote a single constant" rust#145237 **Link:** https://github.com/rust-lang/rust/issues/145237 ### "`ref` patterns can const-promote a single constant more than once, and can both const-promote and move from the same value." rust#145555 **Link:** https://github.com/rust-lang/rust/issues/145555 ### "Uplifts and extends `clippy::needless-maybe-sized` into rustc" rust#145924 **Link:** https://github.com/rust-lang/rust/pull/145924 ### "Decide about future of `rustc_legacy_const_generics`" rust#146613 **Link:** https://github.com/rust-lang/rust/issues/146613 ### "Lint against inherent methods on types implementing `Receiver` and `Deref`" rust#151583 **Link:** https://github.com/rust-lang/rust/issues/151583 ### "Cargo script edition policy (lang/edition aspects)" rust#152254 **Link:** https://github.com/rust-lang/rust/issues/152254 ### "Revise decision process: champion vs FCP decisions" lang-team#360 **Link:** https://github.com/rust-lang/lang-team/pull/360 ### "Tracking Issue for enum access in offset_of" rust#120141 **Link:** https://github.com/rust-lang/rust/issues/120141 ### "Stabilize the `breakpoint` function" rust#142325 **Link:** https://github.com/rust-lang/rust/pull/142325 ## Project goals ### "Const Generics" rust-project-goals#100 **Link:** https://github.com/rust-lang/rust-project-goals/issues/100 ### "Ergonomic ref-counting: RFC decision and preview" rust-project-goals#107 **Link:** https://github.com/rust-lang/rust-project-goals/issues/107 ### "Finish the std::offload module" rust-project-goals#109 **Link:** https://github.com/rust-lang/rust-project-goals/issues/109 ### "Getting Rust for Linux into stable Rust: language features" rust-project-goals#116 **Link:** https://github.com/rust-lang/rust-project-goals/issues/116 ### "Stabilize cargo-script" rust-project-goals#119 **Link:** https://github.com/rust-lang/rust-project-goals/issues/119 ### "SVE and SME on AArch64" rust-project-goals#270 **Link:** https://github.com/rust-lang/rust-project-goals/issues/270 ### "Unsafe Fields" rust-project-goals#273 **Link:** https://github.com/rust-lang/rust-project-goals/issues/273 ### "C++/Rust Interop Problem Space Mapping" rust-project-goals#388 **Link:** https://github.com/rust-lang/rust-project-goals/issues/388 ### "Continue Experimentation with Pin Ergonomics" rust-project-goals#389 **Link:** https://github.com/rust-lang/rust-project-goals/issues/389 ### "Design a language feature to solve Field Projections" rust-project-goals#390 **Link:** https://github.com/rust-lang/rust-project-goals/issues/390 ### "Develop the capabilities to keep the FLS up to date" rust-project-goals#391 **Link:** https://github.com/rust-lang/rust-project-goals/issues/391 ### "Evolving trait hierarchies" rust-project-goals#393 **Link:** https://github.com/rust-lang/rust-project-goals/issues/393 ### "In-place initialization" rust-project-goals#395 **Link:** https://github.com/rust-lang/rust-project-goals/issues/395 ### "MIR move elimination" rust-project-goals#396 **Link:** https://github.com/rust-lang/rust-project-goals/issues/396 ### "Reborrow traits" rust-project-goals#399 **Link:** https://github.com/rust-lang/rust-project-goals/issues/399 ### "reflection and comptime" rust-project-goals#406 **Link:** https://github.com/rust-lang/rust-project-goals/issues/406

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.