2022-05-31 minutes

Author: nikomatsakis

minutes/2022-05-31.md

@@ -0,0 +1,301 @@
+---
+title: Triage meeting 2022-05-31
+tags: triage-meeting
+---
+
+# T-lang meeting agenda
+
+* Meeting date: 2022-05-31
+ 
+## Attendance
+
+* Team members: pnkfelix, joshtriplett
+* Others: simulacrum
+
+## Meeting roles
+
+* Action item scribe: simulacrum
+* Note-taker: pnkfelix
+
+## Additional agenda items
+
+- Kangrejos - Rust in Linux conference (workshop/summit), in Spain in mid-August (after RustConf)
+    - planned in-person; no known plan to support hybrid for this specific event
+
+- Unwinding from Drop impl
+    - Amanieu seeking next steps on this
+    - Rough consensus: we need a clear story for what should be done by applications that want to never stop (e.g. web servers catching panics within requests and returning 500 Internal Server Error)
+
+- cfg_accessible being worked on
+    - https://github.com/rust-lang/rust/pull/97391
+    - May allow unblocking cfg_accessible
+    - Discussion of certain implementation details, relating to trying to use feature in current-crate
+    - Josh points out that the main use-case for this feature is for conditionalizing on accessibilty from *other crates*, so we would be happy if this feature simply errored out with "not supported" if you tried to apply it to something in the current crate.
+     
+## Action item review
+
+* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
+
+## Pending lang team project proposals
+### "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
+
+
+
+## PRs on the lang-team repo
+
+None.
+
+
+
+
+## RFCs waiting to be merged
+
+None.
+
+
+
+
+## Proposed FCPs
+
+**Check your boxes!**
+### "Refined trait implementations" rfcs#3245
+
+**Link:** https://github.com/rust-lang/rfcs/pull/3245
+- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116370994):
+    > Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
+    >
+    > * [x] @cramertj
+    > * [ ] @joshtriplett
+    > * [x] @nikomatsakis
+    > * [x] @pnkfelix
+    > * [ ] @scottmcm
+    >
+    > Concerns:
+    >
+    > * unresolved-question-for-next-edition (https://github.com/rust-lang/rfcs/pull/3245#issuecomment-1116371336)
+    >
+    > 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/rfcs/pull/3245#issuecomment-1116370985):
+    > @rfcbot fcp merge
+    > 
+    > I think we've got consensus on most of this here -- the main question is whether, in the next edition, `#[refine]` ought to be required in order to see the effects of the change or optional (perhaps with a lint). I'm going to separate propose a concern to move this to an unresolved question, I dont' see why it should block this RFC from going forward now.
+
+
+
+
+### "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
+    > * [ ] @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
+
+
+
+
+
+## Active FCPs
+### "Lang: Stabilize usage of rustc_nonnull_optimization_guaranteed on -1" rust#97122
+
+**Link:** https://github.com/rust-lang/rust/issues/97122
+
+- scottmcm: Where are these types exposed?
+- `std::os::unix::io`
+
+### "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
+
+
+### "Stabilize `$$` and `${ignore}` in Rust 1.62.0" rust#95860
+
+**Link:** https://github.com/rust-lang/rust/pull/95860
+
+ * CAD97 had some concerns
+ * CAD97 pointed out that josh themself [got the syntax wrong](https://github.com/rust-lang/rust/pull/95860#issuecomment-1139881538) when interacting on issue; this gave them pause: Is this a sign that the syntax is itself overly confusing?
+     * scottmcm is not sure we should read too much into that 
+     * (the specific concern is the use of `$op(var)` rather than `$op($var)`, since the latter is what many will expect): conflicting mental models of "`$var` is how you name a metavariable" versus "`$var` is the expansion of the metavariable var."
+ * scottmcm: will we ever want random tokens in the input to `$ignore(..)`, or is it always going to be restricted to just metavariables?
+ * scottmcm: should we ask a libs expert about this?
+ * josh: why would this be a libs matter?
+ * scottmcm: "libs" is a placeholder for "person who writes macros a lot"; e.g. dtolnay.
+ * scottmcm: but maybe such people aready weighed in on the RFC?
+ * simulacrum: was the alternative discussed on the RFC?
+ * josh: don't think so
+ * simulacrum: requiring the dollar sign would be backwards compatible with allowing it to be dropped.
+ * josh: the real point is that its an error to include the dollar sign in the first place
+ * pnkfelix: it comes down to that CAD97 question of what the right mental model is: "`$var` is how you name a metavariable" versus "`$var` is the expansion of the metavariable var."
+ * pnkfelix: and this sets a precedent, right? This is the first time we're adding this kind of meta-operation.
+ * josh: could support both options
+ * scottmcm: or we could add the second option when we have another meta-operation that would motivate such support.
+ * simulacrum: for now I would suggest changing to requiring `$var` now and not try to accept the other. It seems like the easier way to start, to force people to write the `$` and then if we can justify taking it out later, that will be an easier shift to make.
+  * pnkfelix: so what would we want if we *were* trying to also adopt the other meta operations like `$count(..)`, `$index(..)`, ...
+  * https://github.com/markbt/rfcs/blob/macro_metavar_expr/text/0000-macro-metavar-expr.md#guide-level-explanation
+  * josh: do we think we (subset of T-lang) can actually make a decision in *this* meeting? or should we raise a concern and resolve the matter asynchronously?
+  * pnkfelix: lets raise a concern.
+   
+### “Warn about dead tuple struct fields” rust#95977
+
+Link: https://github.com/rust-lang/rust/pull/95977
+
+- Do we have a migration plan?
+- Josh: labeled relnotes, we should mention it in release notes and wait a few releases
+- Mark: Should this special case PhantomData? (Mark to post a comment.)
+   
+   
+### "Stabilize `let_chains` in Rust 1.63.0" rust#94927
+
+**Link:** https://github.com/rust-lang/rust/pull/94927
+
+* With this, `let x = ...` now gets treated as an expression in terms of how macro expression parsing works.
+* https://github.com/rust-lang/rust/pull/97295
+* josh: if being conservative in this case is as simple as PR 97295, then I'm going to register that my concern is indeed blocking on landing PR #97295 first.
+
+## Nominated RFCs, PRs and issues NOT discussed this meeting
+### "Covariance-related GAT lifetime mismatch" rust#89352
+
+**Link:** https://github.com/rust-lang/rust/issues/89352
+
+### "Neither require nor imply lifetime bounds on opaque type for well formedness" rust#95474
+
+**Link:** https://github.com/rust-lang/rust/pull/95474
+
+### "nested RPIT and HRTB: unclear semantics and future incompatibility" rust#96194
+
+**Link:** https://github.com/rust-lang/rust/issues/96194
+
+### "Change enum->int casts to not go through MIR casts." rust#96862
+
+**Link:** https://github.com/rust-lang/rust/pull/96862
+
+### "Should `repr(transparent)` require *inhabited* 1-ZSTs?" rust#96921
+
+**Link:** https://github.com/rust-lang/rust/issues/96921
+
+### "clarify how Rust atomics correspond to C++ atomics" rust#97516
+
+**Link:** https://github.com/rust-lang/rust/pull/97516
+
+### "Document the effect of main's return value?" reference#1196
+
+**Link:** https://github.com/rust-lang/reference/issues/1196
+
+### "Specify what happens when casting fat pointers more specifically" reference#1206
+
+**Link:** https://github.com/rust-lang/reference/pull/1206
+
+
+
+