Triage meeting 2022-08-09

--- title: Triage meeting 2022-08-09 tags: triage-meeting --- # T-lang meeting agenda * Meeting date: 2022-08-09 ## Attendance * Team members: Felix, Scott * Others: Mark ## Meeting roles * Action item scribe: Mark * Note-taker: Felix ## Scheduled meetings * Backlog bonanza 2022-08-09 ## 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 (scott, mark and felix discussed some of proposals below, but mostly focused on the abstract question of "can we close some of these", "what criteria should we be using to close a proposal" and "should we add extra criteria/guidance for what one needs *before* a proposal will be considered") ### "Deprecate target_vendor " lang-team#102 **Link:** https://github.com/rust-lang/lang-team/issues/102 ### "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 ### "Interoperability With C++ Destruction Order" lang-team#135 **Link:** https://github.com/rust-lang/lang-team/issues/135 ### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143 **Link:** https://github.com/rust-lang/lang-team/issues/143 ### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147 **Link:** https://github.com/rust-lang/lang-team/issues/147 ### "Async fns in traits" lang-team#150 **Link:** https://github.com/rust-lang/lang-team/issues/150 ### "dyn* trait" lang-team#158 **Link:** https://github.com/rust-lang/lang-team/issues/158 ### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160 **Link:** https://github.com/rust-lang/lang-team/issues/160 ### "Initiative: Ghost types and blocks" lang-team#161 **Link:** https://github.com/rust-lang/lang-team/issues/161 ### "Keyword generics" lang-team#162 **Link:** https://github.com/rust-lang/lang-team/issues/162 ### "Add const evaluatable `where const { <block> }`" lang-team#163 **Link:** https://github.com/rust-lang/lang-team/issues/163 ### "#[repr(Interoperable_2024)]" lang-team#165 **Link:** https://github.com/rust-lang/lang-team/issues/165 ## PRs on the lang-team repo ### "Note design constraints on hypothetical `DynSized`" lang-team#166 **Link:** https://github.com/rust-lang/lang-team/pull/166 (has review action item assigned to niko) ## RFCs waiting to be merged ### "Refined trait implementations" rfcs#3245 **Link:** https://github.com/rust-lang/rfcs/pull/3245 ## Proposed FCPs **Check your boxes!** ### "Tracking issue for RFC 2046, label-break-value" rust#48594 - **Link:** https://github.com/rust-lang/rust/issues/48594 - [**Tracking Comment**](https://github.com/rust-lang/rust/issues/48594#issuecomment-1186582807): > Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [ ] @cramertj > * [x] @joshtriplett > * [ ] @nikomatsakis > * [x] @pnkfelix > * [ ] @scottmcm > > No concerns currently listed. > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/issues/48594#issuecomment-1186582802): > @jyn514 Thank you for the detailed summary! > > @rfcbot merge ### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727 - **Link:** https://github.com/rust-lang/rust/issues/74727 - [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74727#issuecomment-1202855460): > Team member @pnkfelix has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [ ] @cramertj > * [x] @joshtriplett > * [ ] @nikomatsakis > * [x] @pnkfelix > * [ ] @scottmcm > > No concerns currently listed. > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/issues/74727#issuecomment-1202855405): > Okay, I reviewed the update from last year and fixed the first godbolt link (`asm!` has stabilized since it had been posted). > > Its an interesting question, whether to stabilize something that has clear performance issues (in terms of not meeting typical zero-cost expectations). But that is a quality-of-life issue; if users can find utility in this feature even in its current state, then that's an argument for stabilization. > > I'll go ahead and fire off a stabilization FCP. > > @rfcbot fcp merge ### "Tracking Issue for asm_sym" rust#93333 - **Link:** https://github.com/rust-lang/rust/issues/93333 - [**Tracking Comment**](https://github.com/rust-lang/rust/issues/93333#issuecomment-1182038632): > Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [ ] @cramertj > * [x] @joshtriplett > * [ ] @nikomatsakis > * [x] @pnkfelix > * [ ] @scottmcm > > No concerns currently listed. > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/issues/93333#issuecomment-1182038596): > Shall we stabilize sym in `asm!`? > > @rfcbot merge > > EDIT: Link to above stabilization report: https://github.com/rust-lang/rust/issues/93333#issuecomment-1101813004 ### "Stabilize `let else`" rust#93628 - **Link:** https://github.com/rust-lang/rust/pull/93628 - [**Tracking Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585): > Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [x] @cramertj > * [x] @joshtriplett > * [x] @nikomatsakis > * [x] @pnkfelix > * [x] @scottmcm > > Concerns: > > * need-consistency-rvalue-temporary-rules-between-let-and-let-else (https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523) > * ~~not-while-rustfmt-breaks-on-it~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1032936704 > * ~~semicolon~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1059799661 > * ~~stabilization-report~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1033846359 > * ~~summarize-concerns~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1056785904 > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383577): > Shall we stabilize `let else` syntax? We've had many demonstrated uses, including extensively throughout `rust-lang/rust`, we've seen the value of it, and there aren't any known issues with it. > > @rfcbot merge ### "Stabilize generic associated types" rust#96709 - **Link:** https://github.com/rust-lang/rust/pull/96709 - [**Tracking Comment**](https://github.com/rust-lang/rust/pull/96709#issuecomment-1181931476): > Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [x] @compiler-errors > * [ ] @cramertj > * [x] @jackh726 > * [x] @joshtriplett > * [ ] @lcnr > * [x] @nikomatsakis > * [ ] @oli-obk > * [ ] @pnkfelix > * [ ] @scottmcm > * [x] @spastorino > > No concerns currently listed. > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/pull/96709#issuecomment-1181931456): > @rfcbot fcp merge > > Hello all. As the liaison for the generic associated types initiative, I'd like to move to stabilize the MVP of generic-associated-types. The thread has raised up a lot of questions and considerations for the teams to answer. I'm going to break down these questions here. I've also prepared a [page on the GAT repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html) that contains pointers and links to both explain *what* is being stabilized but also the concerns raised on the thread, along with counterpoints, if you'd like to read more. ([Endorsed](https://github.com/rust-lang/rust/pull/96709#issuecomment-1181852925) by @BurntSushi, no less ðŸ˜) > > ### Questions for T-lang > > #### Do we want to expose GATs directly or only use them internally to enable other features? > > GATs are needed internally to model traits that include [async functions] and [return-position impl trait][RPIT]. As a stand-alone feature, they permit users to capture patterns in code that couldn't previously be expressed, whether that is a trait like [`Iterable`] or something more abstract like the [generic scopes] or [many modes] pattern. > > [async functions]: https://rust-lang.github.io/async-fundamentals-initiative/roadmap/static_async_trait.html > [RPIT]: https://rust-lang.github.io/impl-trait-initiative/explainer/rpit_trait.html > [`Iterable`]: https://rust-lang.github.io/generic-associated-types-initiative/design_patterns/iterable.html > [generic scopes]: https://rust-lang.github.io/generic-associated-types-initiative/design_patterns/generic_scopes.html > [many modes]: https://rust-lang.github.io/generic-associated-types-initiative/design_patterns/many_modes.html > > But that strength also means that users will create libraries that employ more abstract patterns, which in turn may make Rust harder to use. As [burntsushi wrote](https://github.com/rust-lang/rust/pull/96709#issuecomment-1168643277), "By increasing the accessibility to that power, that power will in turn be used more frequently and users of the language will need to contend with those abstractions. ... A lot of people have real difficulty understanding abstractions." > > The lang team has to decide which direction to explore: > > * **Deprecate GATs as an end-user feature.** Do not stabilize and instead explore alternatives. At this time there are not real alternatives under consideration, though vague ideas have been discussed. > * **Stabilize lifetime GATs only, deprecate type-based GATs.** This would accommodate many GAT users and allow patterns like [`Iterable`], but disallow the other patterns that abstract over types, helping to avoid the danger of "excess abstraction". > * **Stabilize both type and lifetime GATs now.** We would commit to supporting GATs as an end-user primitive. This does not preclude us from adding future features that leverage GATs as a "desugaring target" as well, if they carry their weight. > > The recommendation of the GATs initiative is to **stabilize the MVP and commit to having GATs as a primitive**, for the following reasons: > > * GATs don't only make things more complex, they make them simpler, too. APIs with GATs are often [easier to understand](https://rust-lang.github.io/generic-associated-types-initiative/mvp/concern-too-complex.html#counterpoint-gats-often-allow-library-authors-to-hide-complexity), as GATs capture the pattern being used directly. This is particularly true when it comes to lifetimes, since the primary alternative to GATs tends to be APIs that involve higher-ranked trait bounds (instead of `T: Iterable`, you get `T: for<'a> CanIter<'a>`, [as you can see in rustc's graph api](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/graph/trait.WithSuccessors.html)). But it's also true for patterns involving types, where the alternatives tend to be [macros or code generation](https://rust-lang.github.io/generic-associated-types-initiative/mvp/concern-too-complex.html#counterpoint-macros-are-not-easier). > * There is no "natural" reason to exclude types/lifetimes, it is an artificial limitation that doesn't arise from anything else. Moreover, most of the confusion that arises from GATs arises with lifetimes just as much as types, so we're not saving much. These sorts of artificial limits ultimately make the language more confusing, because things you would expect to work do not ("why can't I use a type here?"). > * There are a wide variety of patterns that rely on type-dependent GATs to capture. As one particular example, [if we wish to provide traits for async libraries](https://github.com/rust-lang/rust/pull/96709#issuecomment-1173251079) -- e.g., to abstract over an executor that can spawn tasks -- they will almost certainly require type-based GATs -- e.g., to abstract over types like the `JoinHandle<T>` found in [tokio](https://docs.rs/tokio/latest/tokio/task/struct.JoinHandle.html) vs [async-std](https://docs.rs/async-std/latest/async_std/task/struct.JoinHandle.html). You can find other examples in the [design patterns](https://rust-lang.github.io/generic-associated-types-initiative/design_patterns.html) section. > > You can read more details on these pages on the GAT website: > > * [Concern: GATs permit abstractions that make Rust harder to use](https://rust-lang.github.io/generic-associated-types-initiative/mvp/concern-too-complex.html) > * [Concern: we should stabilize lifetime GATs only](https://rust-lang.github.io/generic-associated-types-initiative/mvp/concern-lifetimes-only.html) > > #### Should we stabilize GATs now, or wait until we have improved the known shortcomings? > > The current state of GATs include a number of known shortcomings, ranging from papercuts to severe limitations on expressiveness. Some of these are "by design". For example, we are [requiring users to add `where Self: 'a` bounds explicitly](https://rust-lang.github.io/generic-associated-types-initiative/explainer/required_bounds.html), which leaves room for us to make those either defaulted or optional in the future. We are also prohibiting GATs from being used in `dyn` types for now, and only stabilizing a rather verbose `for<'a>` syntax. > > Other shortcomings are symptoms of deeper refactorings needed on the trait checker and are not truly *GAT* specific, but they arise more often when using GATs: > > * Classification as early- vs late-bound involving type aliases is unrealiable (e.g., [#85533]), this is not a GATs issue but hits GATs when they are put behind an alias > * Associated type normalization, especially in closure signatures, doesn't always work (e.g., [#88382], [#88460]) > * Lack of implied bounds in higher-ranked trait bounds and types can reject valid programs (e.g., [#87748], [#88526], [#91693]) > * Polonius is required to borrow check patterns with GATs (e.g., [#92985]) > > Probably the worst of these is the lack of implied bounds. In a follow-up to this comment, [I described the problem in more detail and the effect that it has on what code works,](https://github.com/rust-lang/rust/pull/96709#issuecomment-1182403490). > > [#85533]: https://github.com/rust-lang/rust/issues/85533 > [#87748]: https://github.com/rust-lang/rust/issues/87748 > [#92985]: https://github.com/rust-lang/rust/issues/92985 > [#88382]: https://github.com/rust-lang/rust/issues/88382 > [#88460]: https://github.com/rust-lang/rust/issues/88460 > [#88526]: https://github.com/rust-lang/rust/issues/88526 > [#91693]: https://github.com/rust-lang/rust/issues/91693 > > This latter class of limitations are hard to convey to users: things just kind of randomly don't work, and it's not obvious that this is the compiler's fault (this is kind of a "worst case" for learnability, since it can trick you into thinking you don't understand the model, when in fact you do). It may be possible to add diagnostics suggesting that GATs could be at fault, but it's hard to know until we try. > > The recommendation of the GAT initiative is to stabilize now, despite the shortcomings, for the following reasons: > > * There are [lots of people and projects successfully using GATs in their current state](https://rust-lang.github.io/generic-associated-types-initiative/design_patterns.html#list-of-projects-using-gats), and [not](https://github.com/rust-lang/rust/pull/96709#issuecomment-1131885602) [only](https://github.com/rust-lang/rust/pull/96709#issuecomment-1119760258) "type wizards". Despite the limitations, there are a lot of patterns that do work well. > * On the other side, [this is a good comment](https://github.com/rust-lang/rust/pull/96709#issuecomment-1126690737) from someone who found the current state confusing, which also includes some points on possible variations on the syntax that could be considered, e.g., `type fn` instead of `type`. Thanks for the thoughtful feedback, @ZoopOTheGoop! > * [Lacking GATs is *itself* a usability hazard.](https://github.com/rust-lang/rust/pull/96709#issuecomment-1130190157) The workarounds for not having GATs are often really complex and also suffer from confusing error messages and poor usability. > * We now have the [types team] and it is functioning pretty well, which helps give confidence that we will be able to address these deeper issues (as well as land smaller improvements). For example, [a-mir-formality was recently extended to model a fix for the implied bounds problem](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md), though it's not clear yet how quickly we can land that work in rustc. > * In general, it's better to offer an incomplete solution than no solution at all. Consider async functions -- there's lots that remains to be done to make them more usable, but aren't we glad they exist on stable? > > [types team]: https://github.com/rust-lang/types-team > > You can read more details on these pages on the GAT website: > > * [Concern: GATs are too hard to learn, especially in their current state](https://rust-lang.github.io/generic-associated-types-initiative/mvp/concern-too-rough.html) > > ### Questions for T-types > > #### Are we confident we can address the known shortcomings without backwards incompatible changes? > > The stabilization report includes a number of known shortcomings, most of which are independent from GATs (but occur more frequently with GATs) -- e.g., interactions with early- vs late-bounds, shortcomings of normalization, etc. Do we feel confident that, if we stabilize now, we are going to be able to address those concerns without requiring changes to the user-facing syntax? > > The recommendation of the GAT initiative is yes, we can, as most of the shortcomings are in fact orthogonal to GATs (e.g., polonius, implied bounds on HRTB, etc). See the Frequently Asked Questions below for a few more details. > > #### Are we confident that we have the right rules for required bounds? > > @QuineDot raised the point that the required bounds *as implemented* do not match the documentation. In particular, the implementation examines methods where a GAT appears in the return type to determine required bounds, but doesn't consider GATs that appear in argument position: > > ```rust > trait LendingIterator { > type Item<'a>; > > fn next(&mut self) -> Self::Item<'_>; > // ^^ > // > // Because of reference, we require `Self: 'a` > // on the GAT above. > > fn push_back<'s>(&'s mut self, item: Self::Item<'s>); > // ^^^^^^^^^^^^^^ > // > // But this method would not trigger any such > // requirement. > } > ``` > > Obviously, we need to bring the documentation and the implementation into agreement. @jackh726 plans to investigate whether to extend the impl to consider GATs appearing in inputs and where-clauses, or modify the spec. > > Ignoring that detail, the question is whether we feel confident that the required bounds are covering a *large enough* set of relationships. The goal is to leave room for us to add relationships by default in the future (should we choose to go that way); we may also opt to convert the existing error into a lint, and make it optional to add these where-clauses. > > The recommendation of the GAT initiative is that, yes, the [current rules](https://rust-lang.github.io/generic-associated-types-initiative/design-discussions/outlives-defaults.html#reference-rules) suffice (pending invesigation of the above point). They are fairly general and basically uncover any relationships that exist between items. Even if find cases that are overlooked, those cases are likely to be quite obscure and can be accommodated through an edition at worst. > > ### Questions for the thread > > #### Are there things that should be in this FCP but are not? > > I've tried to capture all the major themes I saw in the thread, but there's a lot, and I could've missed something. Feel free to raise points you feel were overlooked and I'll consider whether to add them in. Similarly, if you see any points in the FAQ below that you feel could be made more accurate, let me know. > > ### Frequently asked questions > > These questions are meant to be statements of fact, or at least "informed opinion", not arguments for or against stabilizing GATs. > > #### What points of confusion are we "locking in" by stabilizing now? > > Put another way, we are locking in some bits of syntax now. What are the sources of confusion we have seen with those bits of syntax? > > **The distinction between *ensures clauses* and *where clauses*.** Given a trait like this: > ```rust trait WidgetFactory { type Item<T>: Display where T: Debug; } ``` > > The `Display` bound indicates the impl must prove that `Item` is `Display`, but the `T: Debug` bound must be satisfied at the point where the type `F::Item<X>` is written (i.e., we must show that `X: Debug` to reference the GAT). [This has led to some confusion in the past](https://github.com/rust-lang/rust/issues/87831), and to some extent this is inherent in the syntax. > > **The role of `<'a>` in `Foo<Bar<'a> = ...>` bounds.** Consider this function `foo`: > > ```rust > fn foo<'a, T>() > where > T: Iterable<Item<'a> = &'a u32> > ``` > > The where clause on `foo` states that, when a `T` is iterated with the specific lifetime `'a`, it will yield `&'a u32` values. This is unlikely to be what the user wanted. They probably wanted `for<'a> T: Iterable<Item<'a> = &'a u32>` -- i.e., to give the "pattern" of types that result, and not the result for some specific lifetime. > > When you consider a similar example, but using types, the current syntax seems less surprising: > ```rust fn foo<T>() where T: Database<RefCount<u32> = Rc<u32>> ``` > > In general, Rust uses `Foo<T>` both for defining a parameter `T` and for referencing an existing type `T`, depending on context. This can lead to confusion in other places, as well. For example, many users are suprised that `impl MyStruct<T>` does not define a type parameter `T`, but rather references an existing type: > ```rust= struct MyStruct<T> { // ^ defines a type parameter T } impl MyStruct<T> { // ^ references a type T } ``` > > #### What is the estimate of how quickly we can fix the various known shortcomings? > > We can probably put up custom diagnostics relatively quickly. > > Landing shorthands or improved syntax for things like `T: for<'a> Iterator<Item<'a> = &'a u32>` is easy to code, but we have to reach consensus on what to do. > > Fixing the deeper problems like implied bounds, poloniues is harder. We may have improved implied bounds by end of year, but landing polonius (for example) will take more than that. Hard to give meaningful estimates at this time. > > #### Where are the biggest backwards compatibility risks? > > Most of the choices that we are stabilizing now are "forced" by existing bits of Rust syntax and semantics, and seem like somthing we would want to support no matter what. For example, the fact that `'a` works in this example seems potentially surprising, but required for consistency with the language overall... > ```rust fn do_something<'a>(...) where T: Iterable<Item<'a> = &'a u32> ``` > > ...though we have considered a lint suggesting this clause be rewritten to `T::Item<'a> = &'a u32`, assuming we ever accept bounds of that form; see also [#20041]. > > Similarly, while we would like to accept other notations for higher-ranked trait-bounds, the following syntax seems "implied" by Rust's existing constructs: > ```rust T: for<'a> Iterable<Item<'a> = &'a u32> ``` > > In other words, even if we later add support for `T: Iterable<for<'a> Item<'a> = &'a u32>` or `T: Iterable<Item<'_> = &'a u32>`, > > [#20041]: https://github.com/rust-lang/rust/issues/20041 > > The major exception is the ["required bounds"](https://rust-lang.github.io/generic-associated-types-initiative/design-discussions/outlives-defaults.html) rules. As we explain on the GAT repo webpage, [the rules are fairly general](https://rust-lang.github.io/generic-associated-types-initiative/design-discussions/outlives-defaults.html#how-do-you-know-youve-gotten-the-exact-rules-for-required-bounds-correct-for-backcompat). If we *do* decide to have (some subset of) the required bounds be added as defaults (and not written explicitly), it's always possible we'll wish we had different rules, but any such cases seem likely to be fairly obscure. We can manage that through an edition, in the worst case, or possibly by close cooperation with existing crate authors. > > #### What routes are we closing off by stabilizing now? > > Obviously, we would be closing off a world in which we do not have GATs at all. We are not closing off future extensions that might make GATs less necessary, like further improvements to `-> impl Trait` notation or nikomatsakis's wacky proposal for [associated types that are nested within other trait items](https://github.com/rust-lang/rust/pull/96709#issuecomment-1167769172), though we are reducing the motivation for those approaches significantly by giving people a more general primitive. > > Apart from that, we are closing off a world where the syntax `Iterable<Item<'a> = &'a u32>` has an implied forall binder (which is, admittedly, likely the most common thing people want in that place). > ### "Holding a non-Send Copy type across a yield should be allowed" rust#99104 - **Link:** https://github.com/rust-lang/rust/issues/99104 - [**Tracking Comment**](https://github.com/rust-lang/rust/issues/99104#issuecomment-1201982157): > Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: > > * [ ] @cramertj > * [x] @joshtriplett > * [ ] @nikomatsakis > * [ ] @pnkfelix > * [ ] @scottmcm > > No concerns currently listed. > > Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! > > See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me. - [**Initiating Comment**](https://github.com/rust-lang/rust/issues/99104#issuecomment-1201982136): > @rfcbot merge ## Active FCPs Meta-point: Mark pointed out that all-but-the-first of the items on this list are lang-team proposals, and so they are showing up in this list because they are tagged with "final-comment-period", but the actual state of many of them is "seconded" (and therefore already cleared for experimentation). All of those **should** be closed, and a corresponding tracking issue (and zulip stream and maybe repo) [should be created](https://lang-team.rust-lang.org/initiatives/process.html#summary). ### "Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585)" rust#71668 **Link:** https://github.com/rust-lang/rust/issues/71668 ### "Deprecate target_vendor " lang-team#102 **Link:** https://github.com/rust-lang/lang-team/issues/102 ### "Positional Associated Types" lang-team#126 **Link:** https://github.com/rust-lang/lang-team/issues/126 ### "Interoperability With C++ Destruction Order" lang-team#135 **Link:** https://github.com/rust-lang/lang-team/issues/135 ### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143 **Link:** https://github.com/rust-lang/lang-team/issues/143 ### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147 **Link:** https://github.com/rust-lang/lang-team/issues/147 ### "Async fns in traits" lang-team#150 **Link:** https://github.com/rust-lang/lang-team/issues/150 ### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160 **Link:** https://github.com/rust-lang/lang-team/issues/160 ### "Initiative: Ghost types and blocks" lang-team#161 **Link:** https://github.com/rust-lang/lang-team/issues/161 ### "Keyword generics" lang-team#162 **Link:** https://github.com/rust-lang/lang-team/issues/162 ## P-critical issues None. ## Nominated RFCs, PRs and issues discussed this meeting ### "Strengthen invalid_value lint to forbid uninit primitives, adjust docs to say that's UB" rust#98919 **Link:** https://github.com/rust-lang/rust/pull/98919 * scott: to me this is an obvious "yes" * mark: I think Josh is the main holdout for alternatives * mark: scott should FCP Merge and let Josh post concerns. ### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503 **Link:** https://github.com/rust-lang/rust/issues/54503 (felix and mark discuss mark's example from 2022-08-08: the potential for "action at a distance" under mark's model shows a potential anti-pattern of putting `#[expect]` at module scope; it should be placed closer to the point where the lint should occur.) mark: next step here is probably to continue discussion with xFrednet on the issue. ### "Don't allow unwinding from Drop impls" rfcs#3288 **Link:** https://github.com/rust-lang/rfcs/pull/3288 (This was discussed [28 days ago](https://github.com/rust-lang/rfcs/pull/3288#issuecomment-1182096605); we're going to remove the nomination tag.) ### "Tracking Issue for enabling `elided_lifetimes_in_paths` lints" rust#91639 **Link:** https://github.com/rust-lang/rust/issues/91639 * mark: we know that not all lifetime annotations are useful, but we don't have an algorithm for determining which ones are not useful. * scott: maybe we need lint-group dedicated to providing guidance here. * mark+scott: maybe "all lifetimes in return type" is a potential starting point * scott: I can write a comment saying "the lints in their current state aren't quite ready to be enabled-by-default; we think they should be split into separate more specific things: lifetimes in return type, lifetimes in argument type used by elision" * mark: not references though, don't want `&'_ str` * scott: yes, that's the way the lint already works * felix: do we want to push on `'..` or something similar to move this forward? * mark: in practice what I really want is a way to say "i'm adding a lifetime to this data type; please just insert it in all the places that I haven't gotten around to porting yet" * mark: in practice the common shift is from zero lifetimes to one lifetime. `'..` won't resolve that unless people go around putting `<'..>` **everywhere** (namely places that are otherwise not at all generic today) ## Nominated RFCs, PRs and issues NOT discussed this meeting ### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727 **Link:** https://github.com/rust-lang/rust/issues/74727 ### "Allow `impl Fn() -> impl Trait` in return position" rust#93582 **Link:** https://github.com/rust-lang/rust/pull/93582 ### "`#[track_caller]` erroneously points to macro call" rust#95152 **Link:** https://github.com/rust-lang/rust/issues/95152 ### "Implement pointee metadata unsizing via a TypedMetadata<T> container" rust#97052 **Link:** https://github.com/rust-lang/rust/pull/97052 ### "Make forward compatibility lint deprecated_cfg_attr_crate_type_name deny by default" rust#99784 **Link:** https://github.com/rust-lang/rust/pull/99784

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.