Triage meeting 2023-09-26

--- title: Triage meeting 2023-09-26 tags: T-lang, triage-meeting, minutes date: 2023-09-26 discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-09-26 url: https://hackmd.io/A84ad0daTz6lYVKOeQNHFA --- # T-lang meeting agenda * Meeting date: 2023-09-26 ## Attendance * Team members: nikomatsakis, tmandry, scottmcm * Others: TC, David ## Meeting roles * Minutes, driver: TC ## Scheduled meetings - 2023-09-12: "RFC review: Inherent Trait Impls -- RFC#2375" [#217](https://github.com/rust-lang/lang-team/issues/217) - 2023-09-19: "RFC review: Add f16 and f128 float types -- RFC#3453" [#218](https://github.com/rust-lang/lang-team/issues/218) - 2023-09-27: "RFC review: MaybeDangling -- RFCS#3336" [#219](https://github.com/rust-lang/lang-team/issues/219) Edit the schedule here: https://github.com/orgs/rust-lang/projects/31/views/7. ## Announcements or custom items ### Putting minutes into the `lang-team` repo nikomatsakis: Let's get our minutes out of hackmd and into the `lang-team` git repository. Maybe we can write a script. That would be a good thing for us to do. TC, would you be open to helping to get these into the repository? TC: Yes. That would be compatible with my workflow. tmandry: Devil's advocate: why do we care? What's wrong with hackmd.io? nikomatsakis: We can't grep it, the minutes are not in one place, and I'm concerned about longevity of HackMD. We know that the git history will be preserved; I'm not so sure about HackMD. And I'd rather have the storage for the minutes centralized. ## Nominated RFCs, PRs and issues ### "Lifetime Capture Rules 2024" rfcs#3498 **Link:** https://github.com/rust-lang/rfcs/pull/3498 TC: In the [design meeting](https://hackmd.io/sFaSIMJOQcuwCdnUvCxtuQ) on 2023-07-26, we discussed the new lifetime capture rules for Rust 2024, which were needed (for among other reasons) to unblock RPITIT, and we came to the following consensus: > ### 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.) TC: The [proposed RFC](https://github.com/traviscross/rfcs/blob/TC/lifetime-capture-rules-2024/text/3498-lifetime-capture-rules-2024.md) has now been posted and the [PR](https://github.com/rust-lang/rfcs/pull/3498) for it is up. Editorially, this document has certain improvements and clarifications from the one we discussed (prompted in part by that discussion), however it is exactly the same in all normative respects. TC: Unless there are any questions, I propose that people review and check their boxes, and we plan to discuss it next meeting if it hasn't yet gone into FCP by that time. *Consensus*: +1. ### "Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822 **Link:** https://github.com/rust-lang/rust/pull/115822 TC: There has been various discussion on this issue which nikomatsakis has summarized in two documents: - [Given that we don’t have RTN, what should we stabilize?](https://hackmd.io/@nikomatsakis/rkyp2Iw16) - [Interaction between outlives bounds and capture semantics](https://hackmd.io/@nikomatsakis/SJXnALD16) The takeaway is that while this stabilization will not deliver the entire story, as it's missing a solution to the `Send` bounds problem and dynamic dispatch, it's forward-compatible with any anticipated solutions to those problems, and even with the current limitations, it delivers a lot of value to many users today. nikomatsakis and tmandry have collaborated on a T-lang blog post to this effect: - [Impl trait in traits is ready, async fn is not (but it’s getting close)](https://hackmd.io/xy3aQ8XHTJePmjcky0WC_w) The current plan is to proceed with the [stabilization report](https://github.com/rust-lang/rust/pull/115822#issue-1895007848) as proposed. nikomatsakis has [proposed FCP merge](https://github.com/rust-lang/rust/pull/115822#issuecomment-1731161565). There are three open concerns: - When someone uses AFIT in a trait definition, we plan to lint against that and suggest using RPITIT instead due to the `Send` bounds problem. nikomatsakis has opened a concern pending the finalization of the plan for this lint. - CE is updating the Rust reference and nikomatsakis and tmandry are working on the blog post above; nikomatsakis raised a concern pending these documents being complete. - lcnr wants time to review and has raised a concern to that effect. TC: Is there anything people want to discuss to move this forward in this meeting? NM: The first thing I want to do is resolve this lint concern. NM: It seems simpler to lint all of the time rather than checking visibility. Even users not exporting interfaces may get themselves into trouble. tmandry: I go back and forth on this. Linting on everything makes it easy for people to use the compiler to check whether the feature is ready yet. NM: It's also a two-way door in every way. TC: I recall that CE may have had views on this. TC/NM: CE may have preferred that we be more precise. scottmcm: It's hard to know whether people would find the lint annoying on internal things. tmandry: If you're doing single-threaded things, you'll probably allow the lint globally across your entire crate. NM: +1 scottmcm: We usually don't have rustc lints that are, "I acknowledge that this is how rustc works." NM: The lint is on-balance better than a partial stabilization, but it is a new use of lints. scottmcm: It's not a big deal. *Consensus*: This may need more discussion, but it's a two-way door, so the consequences for being wrong here are low. ### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418 **Link:** https://github.com/rust-lang/rust/pull/106418 TC: In the 2023-08-29 meeting we decided that we did have reservations and wanted to see what T-libs-api came back with. scottmcm left a comment in the thread to that effect. Amanieu has since responded with: > We discussed this in the libs-api meeting today. We think there are 2 reasonable options for moving forward here: > > 1. Just make `Discriminant` implement `Ord` unconditionally and document the fact that the ordering should not be treated as semantically significant. > 2. Only provide `Ord` on `Discriminant<T>` if `T: OrderedDiscriminant` (subject to bikeshed). `OrderedDiscriminant` is a marker trait which is included by `#[derive(PartialOrd)]`, but can also be implemented manually. > > There was no consensus on which of these is the best approach, but it should help the discussion move forward. TC: What do we think about that response? scottmcm: Yes, those are the options. NM: +1. scottmcm: Personally, I like the latter better. The other one is interesting. There's a bigger question here related to derive. scottmcm: If the ordering is not semantically significant, how do we make that practically true? NM: I feel like neither of these make me happy. Is there a third option: can we only make this true if `T: PartialOrd`? scottmcm: It doesn't solve changing the order on `Result`. scottmcm: If I manually implement `PartialOrd` in a way that's different from the source order, it's weird to give source order on `Discriminant`. This is where option 2 comes in. NM: But once you derive, then you're locked in... scottmcm: You could write out an equivalent implementation... NM: In principle, you could author your own comparison. It's kind of weird. scottmcm: There may have been discussion about that. The "do nothing" option still works. NM: All the options seem bad. Two feels too complicated, and one rules out things. scottmcm: `AsRepr` / `IntoUnderlying` are the other options. You derive a trait then the compiler does the right thing. NM: This may not be unique to `Discriminant`. I hit this when using B-trees. Maybe we need another trait `SemverStableOrd` / `SemverUnstableOrd`. scottmcm: `BTreeRange` really cares about the order for more than just finding a particular item. That's where I hit this. Using it, e.g., to find everything of variant `B`, I have to rely on the ordering of the things. NM: We could require `SemverOrd` for that particular method. I'd rather err on the side of trusting the user for that case. We could document for the method that if you're hard-coding this, you're implying semver-consistency. tmandry: If we had `SemverUnstableOrd`, which is how I'd personally do it, does that help us out of this problem somehow? NM: `Discriminant` would implement that trait rather than `Ord`. scottmcm: `SemverUnstableOrd` has opt-in from the author, which is a good thing about it. Option one makes me particularly unhappy about that case. If you have `T: PartialOrd` it's not so bad. NM: I don't like the traits that talk about `Discriminant`. It seems like a more general problem. tmandry: Would you have `PartialUnstableOrd` and `UnstableOrd`? scottmcm: You bound on `PartialOrd + StableOrd` if you need it, maybe. NM: We should write this out. Option 2 has this subtle thing where derive `PartialOrd` means more than it did before. You could call it a breaking change to the language. NM: Breaking the muscle memory of "I can take a derive and turn it into a impl" seems bad. NM: How urgent is this? scottmcm: There are stable options that people can use to work around this now, so it's not. scottmcm: We could add a built-in thing that would work within the same crate and thereby not have semver problems. We could change the derives to use that, since they're inside the crate. TC: What makes sense to tell T-libs-api? NM: We should maybe describe to them our discussions. scottmcm: I'll leave a note in the PR. *Consensus*: We'll let them know what we discussed. ### "RFC: Implementable trait aliases" rfcs#3437 **Link:** https://github.com/rust-lang/rfcs/pull/3437 TC: Niko nominated this on 2023-09-16: > One though -- @Jules-Bertholet -- I'm not sure if the RFC covers it, I didn't have time to read in super detail, but I think that if you are implementing `trait Foo = Bar + Baz`, that implies "unioning" the methods from `Bar` and `Baz` into one impl block. Does the RFC discuss this? > > I have, for a long time, wanted the ability to implement a trait **and** its supertraits together in a single impl block, I wonder if it's worth thinking about that as well, though I'd probably want to separate it out from this RFC. TC: This RFC has also been proposed for a design meeting as an RFC read, but it has not yet been scheduled for one. NM: Around AFIT and possibly other areas, there was discussion around how maybe we may want some kind of alias. The problem with that right now is that users have to know about the alias. It's a leaky abstraction. This RFC goes in the direction of fixing that. I've often wished I could implement a trait and a supertrait together. Often there is a fine-grained trait hierarchy that all works together. scottmcm: +1 on that last bit. NM: Maybe we should think about moving this forward. tmandry: As proposed, this only allows implementing a trait alias for a single trait. NM: As proposed, but I'd like to at least support `+ Send`. scottmcm: One of the weird things about this is how you have to rewrite things to a `where` bound. NM: Plus, we killed that syntax when we did GATs. Or at least, we made it where it should be killed. scottmcm: Agreed we should have a better way to implement supertraits. But it's not what this RFC does right now. Maybe we need to work out the boundary rules. Right now, it feels nice but is surprising in what works and does not work. NM: You have A + B and each have a method; we could make that an error, but what if one of them adds the method later... scottmcm: And we have an accepted RFC... NM: That talks about method dispatch. So in that case, we give precedent to the subtrait. So we could do that here and it would be non-breaking. scottmcm: What if, handwaving here, `+ Trait` aliases only work for traits in the same crate... NM: And we could do marker traits; those are guaranteed to have no bounds. scottmcm: Checking the impl vs checking the declaration is an important point. NM, you should write that down somewhere. All OO languages have these problems. tmandry: We hope this situation doesn't appear very often. scottmcm: The idea of "check the impl instead" is better than what I had imagined. tmandry: We give precedence to the subtrait, which is analogous to how we're handling dispatch in that RFC. scottmcm: Right. NM: I'll leave a comment on the RFC. TC: Another place this came up recently is in the discussion of solutions to the orphan impls problem. One way to solve that problem today in Rust is to use a generic parameter on the trait so that each impl can be tagged. This isn't ergonomic today, but if trait aliases could be used just like traits, then it could be made reasonably ergonomic. scottmcm: It would be great to be able to use trait aliases just like traits. NM: Where else can't they be used like traits? TC: One other place, currently is, fully-qualified method call syntax, e.g. `<_ as TraitAlias>::foo()`. This was originally missing from this RFC, but the author has now added it after I pointed this out earlier. tmandry: Agreed we should do something about this. *Consensus*: We'll leave a comment and think about this further. ### "dyn Trait comparison should not include the vtable pointer" rust#106447 **Link:** https://github.com/rust-lang/rust/issues/106447 TC: The FCP to close this issue has been completed. However, @Amanieu is still [looking](https://github.com/rust-lang/rust/issues/106447#issuecomment-1566147477) for a way forward. There's been some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/dyn.20Trait.20pointer.20comparisons) on Zulip about this. scottmcm: I'd love a survey of when people do these comparisons intentionally and for good reasons. scottmcm: There are simple things we could do such as adding methods next to pointer eq. The problem is derives, e.g. where the trait is already implemented, etc. tmandry: Maybe this is an edition migration. scottmcm: We can't edition trait bounds in a meaningful way, that's the problem. It'd help to have an address eq function that people can pass unsized things to. Then we would lint to push people in that direction. NM: +1 on that. It's a step forward. tmandry: +1. *Consensus*: This needs further discussion. ### "fix detecting references to packed unsized fields" rust#115583 **Link:** https://github.com/rust-lang/rust/pull/115583 TC: RalfJ nominated this: > This is a breaking change, but permitted as a soundness fix. tmandry: I'll probably just FCP merge this. scottmcm: It should have an FCP as a breaking change. RalfJ probably wanted to get it in before the branch on Thursday. *Consensus*: We'll proposed FCP merge. ### "Support overriding `warnings` level for a specific lint via command line" rust#113307 **Link:** https://github.com/rust-lang/rust/pull/113307 TC: The feeling in the 2023-09-19 meeting was that we should write down what the semantics are. In terms of moving this issue forward in particular, NM [asked](https://github.com/rust-lang/rust/pull/113307#issuecomment-1726329956) some questions on the ticket. The plan was to discuss this again in the next meeting. NM: I still don't understand what question we're being asked. I'll leave a question to that effect. *Consensus*: We leave this nominated and check back in on it. (The meeting ended here.) ### "`.await` does not perform autoref or autoderef" rust#111546 **Link:** https://github.com/rust-lang/rust/issues/111546 ### "Tracking Issue for the Rust specification" rust#113527 **Link:** https://github.com/rust-lang/rust/issues/113527 TC: We've created a new [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr) for this work. TC: A [job description](https://hackmd.io/tAC6D9SOT1ChxIJ2m1VQ2Q) for the editor has been discussed. There seems to be consensus to move forward on the hiring process. TC: There is [outstanding discussion](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/the.20name.20of.20the.20doc) on the appropriate name of this document. TC: There is an outstanding [discussion](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/goals.20.2F.20conformance.20.2F.20just.20describing.20a.20ref.20impl.3F) ongoing about the goals of the specification. TC: Niko has [proposed](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-lang-descr/topic/selection.20process) to create the team, with pnkfelix and Mara as the leads, and for that team to work to draft a new set of requirements. ### "Disallow *references* to `static mut` [Edition Idea]" rust#114447 **Link:** https://github.com/rust-lang/rust/issues/114447 TC: We discussed on 2023-09-05 and the consensus was in favor of going in this direction. We left a comment with the path forward and labeled it `E-help-wanted`. TC: Are there any particular people we might want to ping who we know might have an interest in this? ### "Non-temporal stores (and _mm_stream operations in stdarch) break our memory model" rust#114582 **Link:** https://github.com/rust-lang/rust/issues/114582 TC: We [discussed](https://hackmd.io/ZJiCNtIwTE2V2arUsabJ6g) this on 2023-08-15. > @**RalfJ** points out that certain compiler intrinsics don't fit within the memory model of the Rust Abstract Machine. For this one in particular, in the time between doing a non-temporal store and before doing a store fence, things are a bit nuts. But this has a performance benefit as it bypasses the cache, so "fixing" it by eliminating the performance benefit isn't a good option. The meeting consensus was to table this while looking for ways to raise awareness. As @**scottmcm** said, "it wouldn't be the first thing you could do in unsafe that turns out to be sketchy." TC: Some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-08-15) followed about this issue after the meeting. ### "const-eval: make misalignment a hard error" rust#115524 **Link:** https://github.com/rust-lang/rust/pull/115524 TC: In the 2023-09-19 meeting, we decided to propose FCP merge. ### "const_eval: allow function pointer signatures containing &mut T in const contexts" rust#116015 **Link:** https://github.com/rust-lang/rust/pull/116015 ### "remove 'illegal_floating_point_literal_pattern' future-compat lint" rust#116098 **Link:** https://github.com/rust-lang/rust/pull/116098 ### "MaybeDangling" rfcs#3336 **Link:** https://github.com/rust-lang/rfcs/pull/3336 TC: We discussed this 2023-08-22 and our consensus was to table the issue so that we could look more carefully into the situation offline. We're planning to read this RFC in the design meeting tomorrow. ### "Report monomorphization time errors in dead code, too" rust#112879 **Link:** https://github.com/rust-lang/rust/pull/112879 TC: We're waiting on @oli to investigate an unexpected incremental build-time regression. I made sure that @oli knows that, and knows that we resolved the fundamental question that was blocking this earlier in RFC 3477. ## Pending lang team project proposals None. ## 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 ## RFCs waiting to be merged ### "RFC: Unicode and escape codes in literals" rfcs#3349 **Link:** https://github.com/rust-lang/rfcs/pull/3349 ## `S-waiting-on-team` ### "Tracking issue for dyn upcasting coercion" rust#65991 **Link:** https://github.com/rust-lang/rust/issues/65991 ### "document ABI compatibility" rust#115476 **Link:** https://github.com/rust-lang/rust/pull/115476 ### "const-eval: make misalignment a hard error" rust#115524 **Link:** https://github.com/rust-lang/rust/pull/115524 ### "Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822 **Link:** https://github.com/rust-lang/rust/pull/115822 ## Proposed FCPs **Check your boxes!** ### "RFC: inherent trait implementation" rfcs#2375 - **Link:** https://github.com/rust-lang/rfcs/pull/2375 ### "unsafe attributes" rfcs#3325 - **Link:** https://github.com/rust-lang/rfcs/pull/3325 ### "Add `f16` and `f128` float types" rfcs#3453 - **Link:** https://github.com/rust-lang/rfcs/pull/3453 ### "Tracking issue for dyn upcasting coercion" rust#65991 - **Link:** https://github.com/rust-lang/rust/issues/65991 ### "Stabilise inline_const" rust#104087 - **Link:** https://github.com/rust-lang/rust/pull/104087 ### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378 - **Link:** https://github.com/rust-lang/rust/pull/107378 ### "TAIT defining scope options" rust#107645 - **Link:** https://github.com/rust-lang/rust/issues/107645 ### "Report monomorphization time errors in dead code, too" rust#112879 - **Link:** https://github.com/rust-lang/rust/pull/112879 ### "FCP process: Require 2/3 majority for FCP" rust#114986 - **Link:** https://github.com/rust-lang/rust/issues/114986 ### "`c_unwind` full stabilization request: change in `extern "C"` behavior" rust#115285 - **Link:** https://github.com/rust-lang/rust/issues/115285 ### "Guarantee representation of None in NPO" rust#115333 - **Link:** https://github.com/rust-lang/rust/pull/115333 ### "document ABI compatibility" rust#115476 - **Link:** https://github.com/rust-lang/rust/pull/115476 ### "const-eval: make misalignment a hard error" rust#115524 - **Link:** https://github.com/rust-lang/rust/pull/115524 ### "fix detecting references to packed unsized fields" rust#115583 - **Link:** https://github.com/rust-lang/rust/pull/115583 ### "Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822 - **Link:** https://github.com/rust-lang/rust/pull/115822 ### "Decision: semantics of the `#[expect]` attribute" rust#115980 - **Link:** https://github.com/rust-lang/rust/issues/115980 ## Active FCPs ### "replace 'UB on raw ptr deref' with UB on place projection/access" reference#1387 **Link:** https://github.com/rust-lang/reference/pull/1387 ## P-critical issues None. ## Action item review * [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)