ITE meeting 2023-10-05

--- title: ITE meeting 2023-10-05 tags: impl-trait-everywhere, triage-meeting, minutes date: 2023-10-05 discussion: https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/ITE.20triage.20meeting.202023-10-05 url: https://hackmd.io/iM67_11NQBCuSQbvvVZAOQ --- # ITE meeting agenda - Meeting date: 2023-10-05 ## Attendance - People: CE, TC, tmandry ## Meeting roles - Minutes: TC ## Announcements or custom items ### Blog post for RPITIT TC: What's the status of the blog post we want to go out? tmandry: I think the draft is mostly ready. The question is when we want to publish it. Probably when it's about to hit stable. CE: We may want to post it during beta to get people to test. What did we do for GATs? And where did we post it? tmandry: It went on the main blog: https://blog.rust-lang.org/2022/10/28/gats-stabilization.html CE: So we posted that right before it hit stable. That did seem to work out well for GATs. We could do the same thing here. CE: Except that would put it right after Christmas. tmandry: Maybe let's aim for the beginning of December. all: +1. ### Lint for RPITIT TC: The lint landed. CE: There was the comment from jonhoo suggesting that we warn people that desugaring it will add the bound to their API contract. TC: The thing is, after desugaring it, the bound is obvious. It's written right there. We're already dipping into the territory of having people confirm that they understand how Rust works. Warning about this would seem to go too far. CE: Does one of you want to tell him no? tmandry: I'll tell him no. CE: Thanks to tmandry and TC, by the way, for writing out the words to this lint. ### Type alias impl trait TC: Given what we've said publicly, do we want to talk about how to move TAIT forward in these meetings? CE: There are those questions about TAIT and the new trait solver. We're not sure whether the new solver will be able to model it in a similar enough way to the old one that existing code would continue to work. TC: There is that PR from oli suggesting a minimal stabilization. The idea is that the TAIT goes in a module with one function that must constrain it. CE: There's still the issue of constraining it twice within the function body with two different lifetimes. TC: We could minimize the stabilization even further, e.g. by allowing it to only be constrained once. CE: We could require it to only be constrained by the return type. TC: Exactly. CE: We need to have a good stabilization report. TC: Here's the one I've been keeping: https://hackmd.io/oTC4J-2XRnukxC7lSq_PVA It needs various updates, e.g. for the new lifetime capture rules. If we wanted to pursue a more minimal stabilization, it'd need to be updated for that as well. ## Project board issues ### "Consider alias bounds when computing liveness in NLL" #116040 - **Link:**: https://github.com/rust-lang/rust/pull/116040 TC: I've been saying this is likely to go into the next release. Any reason why it wouldn't? CE: Only if people on T-types don't check their boxes. Ideally it should. TC: Nikomatsakis reviewed it. That was big. CE: I don't feel as strongly as boats, but it would be a shame if this didn't go in during the same release as RPITIT. CE: I do have an draft for a lint if this PR doesn't go in. CE: There is a process issue here. We need a better way to ensure that big teams like T-types move expeditiously to check boxes on FCPs. (The meeting ended here.) ### "AFIT: impl can't add extra lifetime restrictions, unlike non-async" #104689 - **Link:** https://github.com/rust-lang/rust/issues/104689 ### "Weird interaction between specialization and RPITITs" #108309 - **Link:** https://github.com/rust-lang/rust/issues/108309 ### "RPITIT with Send trait marker breaks borrow checker" #111105 - **Link:** https://github.com/rust-lang/rust/issues/111105 ### "`Failed to normalize` `async_fn_in_trait` ICE for indirect recursion of async trait method calls" #112047 - **Link:** https://github.com/rust-lang/rust/issues/112047 ### "Exponential compile times for chained RPITIT" #102527 - **Link:** https://github.com/rust-lang/rust/issues/102527 ### "Mysterious "higher-ranked lifetime error" with async fn in trait and return-type notation" #110963 - **Link:** https://github.com/rust-lang/rust/issues/110963 ### "AFIT: strange errors on circular impls" #112626 - **Link:** https://github.com/rust-lang/rust/issues/112626 ### "Nightly (warning): Async traits Self return requires type specification" #113538 - **Link:** https://github.com/rust-lang/rust/issues/113538 ### "ICE for return_position_impl_trait_in_trait" #105197 - **Link:** https://github.com/rust-lang/rust/issues/105197 ### "hrtb + infer types break auto traits with return type notation " #109924 - **Link:** https://github.com/rust-lang/rust/issues/109924 ### "`async_fn_in_trait` and `return_type_notation` cause awkward awaits" #112569 - **Link:** https://github.com/rust-lang/rust/issues/112569 ## Pending PRs on the impl-trait-initiative repo None. ## Open PRs ### "stricter hidden type wf-check" rust#115008 - **Link:** https://github.com/rust-lang/rust/pull/115008 - **Labels:** S-waiting-on-review, A-impl-trait, T-types, WG-trait-system-refactor ### "Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822 - **Link:** https://github.com/rust-lang/rust/pull/115822 - **Labels:** T-lang, final-comment-period, S-waiting-on-team, disposition-merge, I-lang-nominated, F-async_fn_in_trait, T-types, F-return_position_impl_trait_in_trait