--- title: Triage meeting 2021-12-21 tags: triage-meeting --- # T-lang meeting agenda * Meeting date: 2021-12-21 ## Attendance * Team members: Niko, Josh * Others: simulacrum ## Meeting roles * Action item scribe: simulacrum * Note-taker: ## Scheduled meetings * Tomorrow: * [Heap allocation in constants](https://hackmd.io/JdKPGA2eQ_qSX13pQeKoNg) ## Announcements or custom items (Meeting attendees, feel free to add items here!) ## Action item review * [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) ## Pending lang team project proposals ### "negative impls integrated into coherence" lang-team#96 **Link:** https://github.com/rust-lang/lang-team/issues/96 ### "Deprecate target_vendor " lang-team#102 **Link:** https://github.com/rust-lang/lang-team/issues/102 ### "Async fundamentals initiative" lang-team#116 **Link:** https://github.com/rust-lang/lang-team/issues/116 ### "Attribute for trusted external static declarations" lang-team#118 **Link:** https://github.com/rust-lang/lang-team/issues/118 ### "Prototype Sync & Async Iterator Items (Minimal generators)" lang-team#121 **Link:** https://github.com/rust-lang/lang-team/issues/121 ### "Support platforms with size_t != uintptr_t" lang-team#125 **Link:** https://github.com/rust-lang/lang-team/issues/125 ### "Positional Associated Types" lang-team#126 **Link:** https://github.com/rust-lang/lang-team/issues/126 ### "Heap allocations in constants" lang-team#129 **Link:** https://github.com/rust-lang/lang-team/issues/129 ## PRs on the lang-team repo None. ## RFCs waiting to be merged None. ## Proposed FCPs **Check your boxes!** ### "Change location of where clause on GATs" rust#90076 **Link:** https://github.com/rust-lang/rust/pull/90076 * blocked on 'further thought' concern from Josh * Niko: * still feel this should be changed but my urgency is not super high yet * I want to work through and do a general triage about this * Mark: * User experience report that I was using GATs on betas and I was positively baffled why what I was trying didn't work * Eventually realized that the syntax we currently accept (before the `=`) was what I had to do * Despite being in the design meetings and so forth * Niko: * That matches my experience * Josh: * Can you share that experience on the thread? * Maybe point to some of the code or error messages? * Mark: * I don't think it'd be *new*, but I can write up a short comment * Josh: * Don't personally have an incredibly strong feeling, but I have a mild concern, I'm concerned about both possible locations for the where, in terms of ambiguity. * My main concern is that people on the thread have concerns. If I see folks on the thread no longer have it, I'm happy to drop mine. * Niko: * I do think it's possible that this will just wind up being a controversial call, but that's ok. * Niko: * I do have some further thoughts about GATs but I guess this probably isn't the right meeting for me to go into it, I realize now. I've been working through the RPITIT and implied bounds design and I think that it affects some of the other bits of the overall design (e.g., the default where clauses). * Josh: * One other thought, one of the motivations is the desire to copy from the trait, add an equal sign, and type? * Niko: * It is a common use case that people want to copy from the trait and add an `=` sign, but the difference is where you expect to add it. * Current design is that you would add it at the *end*, but the proposal would change it to placing the `=` sign more in the middle. * cramertj: * It depends where you think people will expect to put it. I think it's rather formatting dependent. * Josh: * What is stable at the moment? * Niko: * Nothing-- what is stable is type aliases with where clauses. * cramertj: * But we probably want both to match. * Niko: * Right, but they have the wrong behavior on type aliases (they get ignored). * Josh: * I agree we want type aliases with where clauses to match -- it would be nice if they weren't ignored of course -- but if we get to the point of urgency on getting GATs stabilized, and this syntax question remains a blocker, as an option could we simply not support where at all, and just say that you need to put the angle bracket syntax? * Niko: * Some common bounds wouldn't fit. The current design requires `where Self: 'a` on virtually every GAT you will use in practice: ```rust trait Foo { type Bar<'a> where Self: 'a; } ``` ## Active FCPs ### "Tracking issue for RFC 2115: In-band lifetime bindings" rust#44524 **Link:** https://github.com/rust-lang/rust/issues/44524 * In FCP, no objections raised. ### "negative impls integrated into coherence" lang-team#96 **Link:** https://github.com/rust-lang/lang-team/issues/96 Action item: - [ ] [2021-06-22]: Niko to merge/close negative impl coherence (Felix to liaision) https://github.com/rust-lang/lang-team/issues/96 ### "Positional Associated Types" lang-team#126 **Link:** https://github.com/rust-lang/lang-team/issues/126 Action item: - [ ] [2021-11-16]: Felix to summarize discussion on https://github.com/rust-lang/lang-team/issues/126 (lang-team discussion, and zulip as well if possible) - in particular, wanted to block on owner accepting investigation tasks. ## P-critical issues None. ## Nominated RFCs, PRs and issues ### "Remove effect of `#[no_link]` attribute on name resolution" rust#92034 **Link:** https://github.com/rust-lang/rust/pull/92034 Points from discussion: * Doesn't seem surprising that saying no-link can cause linker errors * This new behavior is more what we would expect * We could make this more user friendly if it matters, but this is very rarely used * Josh can imagine there may be use cases, e.g. if you don't have dylibs on your system * Josh: Do we need a crater? * Mark: I suspect we'll catch it in the beta run. A quick search found that the vast majority of uses are rustc tests that got forked in random places and some old servo forks. Nothing current. * Josh: We should tag it relnotes, though, right? * Mark: Yes. In any case the beta run regressions wil get bisected and tracked to this.