Triage meeting 2023-10-10

--- title: Triage meeting 2023-10-10 tags: T-lang, triage-meeting, minutes date: 2023-10-10 discussion: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Triage.20meeting.202023-10-10 url: https://hackmd.io/YCOGGiHWQOGqFzj_ws2-rQ --- # T-lang meeting agenda - Meeting date: 2023-10-10 ## Attendance - Team members: tmandry, pnkfelix, scottmcm - Others: TC, eholk, Lokathor, Urgau ## Meeting roles - Minutes, driver: TC ## Scheduled meetings - 2023-10-11: "Meeting proposal: Unsafe extern blocks" [#223](https://github.com/rust-lang/lang-team/issues/223) - 2023-10-18: "Design meeting: Decide about the future for consts in patterns" [#220](https://github.com/rust-lang/lang-team/issues/220) - 2023-10-25: "Design meeting: Implementable trait aliases" [#224](https://github.com/rust-lang/lang-team/issues/224) 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!) ### Rust Survey https://github.com/rust-lang/surveys/pull/243 TC: @scottmcm proposed that we discuss the questions to be asked on the Rust Survey, particularly about the features that people may want added to the language. pnkfelix: These are phrased as lists of features, but maybe it would be better to phrase it as problems areas to solve. TC: The challenge with problem areas is that people tend to want all problems solved. tmandry: Maybe we could ask people to do a ranking. pnkfelix: There's a difference between features that affect the API that people can provide from features that let people write the kind of code they want to write. eholk: Looking at the list of features, would people even know what things like higher-kinded types are? Maybe we should say what kind of code features like that would let you write. TC: There's tension between that and the compression needed for a survey. Macroexpanding each feature would probably make the length untenable. Also, if a lot of people see "HKT" and say, "yes, I want that", the fact that those people even know about it provides non-zero information. tmandry: We should ask a survey expert. scottmcm: Thinking out loud: Which of these is causing you the most trouble these days?: - Implementing things on tuples - Splitting things across crates - Having to do iterator implementations manually - Not being able to do enough in `const fn` - Needing to drop down to C ABI for rust plugins - ... scottmcm: What's the timeline here? tmandry: It usually happens in the fall. Lokathor: We could discuss on Zulip. *Consensus*: Let's discuss on Zulip. ## Nominated RFCs, PRs, and issues ### "document ABI compatibility" rust#115476 **Link:** https://github.com/rust-lang/rust/pull/115476 TC: RalfJ is asking for us to remove a concern that was filed to check that T-opsem had looked at this. They have now. pnkfelix: I'll resolve the concern. *Concensus*: We'll resolve the concern and this will go into FCP. ### "const-eval: make misalignment a hard error" rust#115524 **Link:** https://github.com/rust-lang/rust/pull/115524 TC: This is in FCP. Any objections to unnominating? *Consensus*: Let's unnominate. ### "const_eval: allow function pointer signatures containing &mut T in const contexts" rust#116015 **Link:** https://github.com/rust-lang/rust/pull/116015 TC: This is in FCP. Any objections to unnominating? *Consensus*: Let's unnominate. ### "Reserve `gen` keyword for `gen {}` blocks and `gen fn` in 2024 edition" rust#116447 **Link:** https://github.com/rust-lang/rust/pull/116447 TC: @oli raised this issue: > `gen fn foo() {}` already did not parse on any edition, so I just added a custom (slightly incorrect) error message for it, when the 2024 edition is enabled. > > `gen {}` blocks are technically able to exist, as someone could name a struct `gen` and then try to initialize its fields. With this PR this will be forbidden in 2024. I could start linting it on older editions. > > Historically (async blocks, `dyn` traits) we've first linted on one edition, then errored in the follow up edition. That would be to lint in 2024 and hard error in 2027. I guess we could go with `k#gen` for 2024 edition. > > Generators tracking issue #43122 > > The semantics of gen blocks and `gen fn` are deliberately omitted from this PR. While I have opinions on those, development on them should follow the usual T-lang path for new features > > r? lang TC: @scottmcm nominated: > Note that since [rust-lang/rfcs#2441 (comment)](https://github.com/rust-lang/rfcs/pull/2441#issuecomment-395256368) lang has said that we're not pre-reserving keywords for features that haven't been RFC'd. > > Thus the default expectation here is that this will be written using the syntax space reserved in https://rust-lang.github.io/rfcs/3101-reserved_prefixes.html for now, and keyword reservations will happen along with the semantic RFC. > > I think that `gen fn` could probably happen without that, though, by having `gen` there be a contextual keyword. But in expressions, it would be `k#gen { ... }` (or `do gen { ... }` or whatever) for now, even in a future edition. > > (Nominated for lang meeting discussion regardless.) eholk: Do we want to RFC this before 2024? pnkfelix: There is an RFC linked from the issue. https://github.com/rust-lang/rfcs/pull/2033 (Discussion that it being an experimental RFC is good enough for reserving a keyword.) Lokathor: Perhaps we should do a quick RFC to reserve the keyword based on the earlier RFC. Then we're policy compliant. tmandry: Is that the policy? scottmcm: I notice the RFC doesn't contain generator blocks. Lokathor: Right. tmandry: It needs an RFC, but it could be a small one. eholk: Do we think that `gen` is a common variable name? scottmcm: But the RFC can deal with that. pnkfelix: We shouldn't block the experiment on the RFC. scottmcm: The experiment should move forward with `k#gen`. pnkfelix: I'm concerned about the semantics holding up getting the keyword into 2024. scottmcm: The RFC about not reserving covered this case, e.g. not repeating the experience of `throw`. eholk: This seems distinguishable. We're much closer here. tmandry: I'm in favor of reserving the keyword on the basis of the fact that this is a feature that we want. TC: What if we proposed an RFC that says that we're going to write a later RFC to pin down the semantics (on the basis of the experiment being run), but we're going to reserve the keyword now. scottmcm: It sounds though, based on what eholk said, that we may have the semantics somewhat pinned down based on the async/await work. eholk: That's true, but there are some open questions. scottmcm: Maybe the RFC should say the semantics we know now, and leave open the questions that are open. TC: Who has the most context on this? eholk: Myself and tmandry. tmandry: And we should ask @oli. scottmcm: I'll write a comment on the thread. *Consensus*: We'll try to find someone to write an RFC for this, and we'll leave a comment on the issue that we're looking for one. ### "types team / lang team interaction" rust#116557 **Link:** https://github.com/rust-lang/rust/issues/116557 TC: nikomatsakis nominated this: > We had some discussion about types/lang team interaction. We concluded a few things: > > * Pinging the team like @rust-lang/lang is not an effective way to get attention. Nomination is the only official way to get attention. > * It's ok to nominate things in an "advisory" capacity but not block (e.g., landing a PR), particularly as most any action can ultimately be reversed. But right now, triagebot doesn't track closed issues, so that's a bit risky. > > Action items: > > * We should fix triagebot to track closed issues. *Consensus*: Let's discuss this when nikomatsakis is available. ### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378 **Link:** https://github.com/rust-lang/rust/pull/107378 TC: This had been waiting on the author to answer some questions. Those have now been answered, and tmandry nominated this for further discussion. tmandry: The answer to our questions on whether the lifetime should be higher-ranked is that we had accidentally stabilized this with `async fn`. pnkfelix: If we think this is wrong, we shouldn't expand the amount of code affected. tmandry: I'm not obvious what the correct behavior is. Maybe we want to have Niko to discuss. scottmcm: I agree with tmandry that associated types are outputs <https://github.com/rust-lang/rfcs/pull/2548>, whereas `Self` and generics are inputs. TC: We could ask for a document that does a de novo analysis. I.e., setting aside the accidental stabilization, we should have a write-up about the pros and cons for each choice. tmandry: I'll leave some thoughts on the PR. *Consensus*: We should think further about this and discuss with nikomatsakis. We'll ask for more analysis on the PR. ### "Guarantee representation of None in NPO" rust#115333 **Link:** https://github.com/rust-lang/rust/pull/115333 TC: @tmandry nominated this: > I'll proxy @the8472's concern, to make sure we come to a resolution before merging. I'm also re-nominating for lang team discussion so the team has a chance to flag any concerns they have with this change. > > Since the change would be _more_ conservative than the original proposal, though, I don't think it requires a new FCP. > > @rfcbot concern None-value of `Option<fat-reference>` @rustbot label I-lang-nominated tmandry: I wanted people to be aware here. We don't need to redo the FCP since we're making it more conservative. scottmcm: +1. Since we don't guarantee the representation of fat pointers in general, it would be strange to do here. pnkfelix: +1. tmandry: I'll leave a note. *Consensus*: We'll reduce the PR to the more conservative variant and move forward with the proposed FCP. ### "make matching on NaN a hard error" rust#116284 **Link:** https://github.com/rust-lang/rust/pull/116284 TC: In the 2023-10-03 meeting, we discussed and decided to ask Ralf what he thinks we should do. Ralf replied: > > First, what is the motivation to eliminate NaN specifically? > > NaN is by far the least well-behaved class of float values when it comes to comparison, since they don't even satisfy reflexivity. No matter the mental model for `match`, it seems very hard to justify a value not even matching itself. > > > Second, do we have a sense for the overall "plan" around the semantics of pattern matching and floating point values? At some point we expected to remove that, but now it seems like we are allowing floats, presumably with today's semantics, is that correct? > > There was the plan to disallow floats entirely as part of the move to enforcing structural matching (this even got [RFC'd](https://rust-lang.github.io/rfcs/1445-restrict-constants-in-patterns.html)). Then t-lang rejected #84045, which is a departure from that plan. If t-lang has a long-term plan here than you didn't tell us about it. :) TC: There is some further discussion on the issue. tmandry: We can unnominate; we have a design meeting next week on this. *Consensus*: We'll discuss tomorrow. ### "remove 'illegal_floating_point_literal_pattern' future-compat lint" rust#116098 **Link:** https://github.com/rust-lang/rust/pull/116098 TC: RalfJ raised this issue: > In #84045 the lang team rejected making this a hard error. So clearly we shouldn't have a lint saying "this will be a hard error in the future". > > Fixes #41620 pnkfelix: Want to discuss this at the design meeting? all: +1. *Consensus*: We'll discuss this at the design meeting next week. ### "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. TC: Is there anything we want to do before unnominating this? Lokathor: Ralf wants us to deprecate or mark as permanently unsound these intrinsics. tmandry: That would seem a disappointing outcome. These are probably useful. Lokathor: One problem is that you want to use these inside a loop, and you'd get bad codegen if you used assembly. tmandry: It seems like we need some way to express this. Lokathor: Ralf's position is that these don't fit in the Rust abstract machine, and that if you're using these, you're not writing Rust code. TC: There is the option to extend the Rust memory model to allow expressing these. That's a big ask, of course. tmandry: Perhaps we should lint/warn on their use. We could use the deprecation machinery. Lokathor: The fastest path in terms of existing infrastructure is deprecating them. tmandry: I'll write a comment that we should lint on this. We can discuss if there's a response next time. Otherwise, let's unnominate. pnkfelix: A lint is a step. It needs serious investigation. Jubilee has been adding the `SFENCE` to people's code across GitHub. TC: That's a great point. We need to suggest to people to add the `SFENCE` in the lint. *Consensus*: We'll propose a lint for this, and we'll discuss it again. (The meeting ended here.) ### "`.await` does not perform autoref or autoderef" rust#111546 **Link:** https://github.com/rust-lang/rust/issues/111546 TC: This was nominated for T-lang (and for T-types) by WG-async. @tmandry said: > We discussed this in a recent wg-async meeting ([notes](https://hackmd.io/G6ULofyXSIS4CK9u-jwYRg)). The consensus was that we thought the change was well-motivated. At the same time, we want to be cautious about introducing problems (namely backwards compatibility). > > There should probably be a crater run of this change, and we should also work through any problematic interactions that could be caused by this change. (@rust-lang/types should probably weigh in.) > > The main motivation for the change is the analogy to `.method()`, as well as to wanting async and sync to feel similarly convenient in most cases. > > Note that there is another analogy that works against this, the analogy to `IntoIterator`, where the lang-effect form (`for _ in foo {}`) does not do autoref/autoderef. However, given that this _looks_ very different from `foo.await`, and taking a reference with that form is significantly more convenient (`for x in &foo` or `for x in foo.iter()` vs `(&foo).await`), it seemed the analogy was stretched pretty thin. So we elected to put more weight on the above two considerations. > > That being said, this change would need lang team signoff. You can consider this comment wg-async's official recommendation to the lang team. ### "Lifetime Capture Rules 2024" rfcs#3498 **Link:** https://github.com/rust-lang/rfcs/pull/3498 TC: FCP merge has been proposed. Some minor edits are in progress, but no serious concerns are outstanding. ### "RFC: Syntax for embedding cargo-script manifests" rfcs#3503 **Link:** https://github.com/rust-lang/rfcs/pull/3503 TC: The following syntax is being proposed for addition to Rust: ````rust #!/usr/bin/env cargo ```cargo [dependencies] clap = { version = "4.2", features = ["derive"] } ``` use clap::Parser; ```` ### "Implement `PartialOrd` and `Ord` for `Discriminant`" rust#106418 **Link:** https://github.com/rust-lang/rust/pull/106418 TC: We discussed in the 2023-09-26 meeting. We decided to simply let T-libs-api know about what we had discussed. Niko [left a comment](https://github.com/rust-lang/rust/pull/106418#issuecomment-1736377423) to the effect that "right now we seem to have no good options." TC: There has since been further discussion on the issue. ### "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. TC: We discussed this in the 2023-09-26 triage meeting without a full resolution, but decided that adding `ptr::addr_eq` may be one small step forward. @pnkfelix proposed this [in the ticket](https://github.com/rust-lang/rust/issues/106447#issuecomment-1741849318) and then [to T-libs-api](https://github.com/rust-lang/libs-team/issues/274). @dtolnay seconded the request and asked for a PR. ### "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? ### "Stabilize `async fn` and return-position `impl Trait` in trait" rust#115822 **Link:** https://github.com/rust-lang/rust/pull/115822 TC: This is in FCP. ### "MaybeDangling" rfcs#3336 **Link:** https://github.com/rust-lang/rfcs/pull/3336 TC: We [discussed](https://hackmd.io/ifgF0ThcTSWvKnYRWEM8nw) this in an RFC read on 2023-09-27. @scottmcm said that he would propose FCP merge. ### "RFC: Implementable trait aliases" rfcs#3437 **Link:** https://github.com/rust-lang/rfcs/pull/3437 TC: This RFC has also been proposed for a design meeting as an RFC read, but it has not yet been scheduled for one. TC: We discussed this in the 2023-09-26 triage meeting. We decided that this needed more discussion and that we'd leave a comment about what was discussed in the issue. Niko has [posted](https://github.com/rust-lang/rfcs/pull/3437#issuecomment-1736102047) that comment. ### "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. ### "Support overriding `warnings` level for a specific lint via command line" rust#113307 **Link:** https://github.com/rust-lang/rust/pull/113307 TC: We discussed in the 2023-09-26 meeting, but were unsure of the question we were being asked. We've [reiterated](https://github.com/rust-lang/rust/pull/113307#issuecomment-1736115331) on the issue a request for clarification. ## Action item review - [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A) ## 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 ### "update membership rules" lang-team#225 **Link:** https://github.com/rust-lang/lang-team/pull/225 ## RFCs waiting to be merged ### "RFC: Unicode and escape codes in literals" rfcs#3349 **Link:** https://github.com/rust-lang/rfcs/pull/3349 ### "Add `f16` and `f128` float types" rfcs#3453 **Link:** https://github.com/rust-lang/rfcs/pull/3453 ## `S-waiting-on-team` ### "Tracking issue for dyn upcasting coercion" rust#65991 **Link:** https://github.com/rust-lang/rust/issues/65991 ### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378 **Link:** https://github.com/rust-lang/rust/pull/107378 ### "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 ### "remove 'illegal_floating_point_literal_pattern' future-compat lint" rust#116098 **Link:** https://github.com/rust-lang/rust/pull/116098 ## 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 ### "Lifetime Capture Rules 2024" rfcs#3498 **Link:** https://github.com/rust-lang/rfcs/pull/3498 ### "Tracking issue for dyn upcasting coercion" rust#65991 **Link:** https://github.com/rust-lang/rust/issues/65991 ### "Tracking Issue for const `mem::discriminant`" rust#69821 **Link:** https://github.com/rust-lang/rust/issues/69821 ### "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 ### "Decision: semantics of the `#[expect]` attribute" rust#115980 **Link:** https://github.com/rust-lang/rust/issues/115980 ### "Stabilize `const_maybe_uninit_zeroed` and `const_mem_zeroed`" rust#116218 **Link:** https://github.com/rust-lang/rust/pull/116218 ### "Stabilize Ratified RISC-V Target Features" rust#116485 **Link:** https://github.com/rust-lang/rust/pull/116485 ## Active FCPs ### "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 ### "const_eval: allow function pointer signatures containing &mut T in const contexts" rust#116015 **Link:** https://github.com/rust-lang/rust/pull/116015 ## P-critical issues None.

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.