Triage meeting 2022-03-15

--- title: Triage meeting 2022-03-15 tags: triage-meeting --- # T-lang meeting agenda * Meeting date: 2022-03-15 ## Attendance * Team members: Niko, Felix, Josh * Others: Mark, David, Lokathor, skippy, Michael Goulet, Mara ## Meeting roles * Action item scribe: Mark * Note-taker: nikomatsakis ## Scheduled meetings - Tomorrow: backlog bonanza - Mar 23: RPITIDT (nikomatsakis/tmandry) - Mar 30: Lint policy (pnkfelix) ## Announcements or custom items ### GATs update nikomatsakis: * jackh726 is working on a stabilization report; * jackh726 is investigating whether we can avoid having two `Iterator` traits. Maybe it is possible to extend `Iterator` trait "in place" with GATs. The idea would be to extend to `Item<'me>` and interpret existing code as "must not depend on the `Item` parameter". pnkfelix: How many traits do you think would be potentially GAT-ified? nikomatsakis: Not every trait, probably `Iterator` and closure traits. simulacrum: Are you thinking about the ecosystem too? nikomatsakis: Are you saying, if you make a new trait where GATs could make sense, should you use it? simulacrum: Right, general guidance, is it a good default to start using GATs immediately? Since presumably it will be a breaking change (modulo outcome of the above). nikomatsakis: Probably our initial advice would be no, the ergonomic hit would be too high, we haven't added the syntactic sugar for cases that "only sometimes need to be GATs". joshtriplett: anything else to cover here? nikomatsakis: no, I think we're good for now, we'll do a design meeting in the future. ## 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 ### "inner crates, aka multiple crates per file" lang-team#139 **Link:** https://github.com/rust-lang/lang-team/issues/139 ### "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 joshtriplett: Allows you to take a fn that is currently safe, mark it as unsafe, but such that you get a *warning* when using it in a safe block. Intended for the environment functions (not safe to use in some multithreaded contexts in which you can't be sure that C code isn't also calling them in parallel). joshtriplett: Original name was `rustc_deprecated_safe` but was renamed to permit "potential stabilization". joshtriplett: Seems like an obvious and good idea. Anyone feel we *shouldn't* do it? nikomatsakis: +1. Let's do it! pnkfelix: I'll second it! nikomatsakis: Follow these steps! https://lang-team.rust-lang.org/initiatives/process/checklists.html#approve-a-proposal pnkfelix: Should we summarize the thread on the issue? nikomatsakis: has there been significant discussion? skippy: not too much, I added a note that we might want to support more places (e.g., traits) eventually. ### Async fn in traits lang-team#150 **Link:** https://github.com/rust-lang/lang-team/issues/150 nikomatsakis: yes, I closed existing "async fundamentals", only question is whether I should second (tmandry will be owner). joshtriplett: not obvious how much person serving as liaison needs to be someone otherwise qualified to be on the types working group, vs just "normal lang reviewer" expertise. nikomatsakis: I don't really see the role of the initiative as being a domain expert, they're meant to help represent lang team pnkfelix: right, I think it's actually good if they lack some of the specialized knowledge, since they can represent "rest of the team" who might not understand it joshtriplett: if someone who is meant to be a liaison is meant to be a proxy for concerns, they're able to raise concerns like "this needs more detailed explanation", less feasible to raise considerations that require the detailed understanding. nikomatsakis: I'm more concerned about the high-level stuff than the low-level details. I think we've got those low-level details covered pretty well between tmandry and I. pnkfelix: Another way to think of it, the failure mode for a meeting where we read a doc is when people show up with a doc that is too complex for team to follow. joshtriplett: I'm willing to serve as liaison if people don't mind me explicitly asking a lot of questions. nikomatsakis: that's a feature, not a bug. great! *joshtriplett seconds it.* ## PRs on the lang-team repo None. ## RFCs waiting to be merged None. ## Proposed FCPs pnkfelix: Would be useful to see concerns that have been raised **Check your boxes!** ### "New Rust attribute to support embedding debugger visualizers" rfcs#3191 **Link:** https://github.com/rust-lang/rfcs/pull/3191 joshtriplett: This attribute references file paths. It uses the `include_str` behavior, not the `#[path]` attribute from `mod`. Probably correct, but also under discussion. ### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216 **Link:** https://github.com/rust-lang/rfcs/pull/3216 nikomatsakis: This proposes ``` for<'a> |x: &'a u32| -> &'a u32 { } ``` Has some limitations. If you use this syntax, all lifetimes must be named, none can be elided, so you can't do: ``` for<'a> |x: &'a u32, y: &u32| -> &'a u32 { } ``` Moves towards closing a gap where today you have to use inference to get some signatures. pnkfelix: Does it support bounds or where clauses? nikomatsakis: No. nikomatsakis: Doesn't like a huge game changer, but it seems like the obvious notation that people will try to use. joshtriplett: Is this "semantically equivalent" to the use of `for` that has been floated for "existential" context elsewhere? e.g., in the middle of a return value, being able to say "I'll take a something of T for any T". nikomatsakis: Probably yes? joshtriplett: I think that's an experimental syntax, not sure where precisely it's supported? pnkfelix: Any change you can find a link? nikomatsakis: You can write today `where for<'a> T: Fn(&'a u32) -> &'a u32`, which would match that initial closure I gave. joshtriplett: Is for an "introducer" nikomatsakis: It's a binder, it says "forall" pnkfelix: Isn't it `where T: for<'a> Fn(&'a u32)` nikomatsakis: they are equivalent and both supported joshtriplett: In this example: ``` fn foo<'a>(x: &'a u32) { let c = for<'b> |arg1: &'a u32, arg2: &'b u32| { .. }; } ``` ``` fn foo<'a>(x: &'a u32) { let c = |arg1: &'a u32, arg2: &u32| { .. }; } ``` nikomatsakis: currently, at least, you need to have some kind of "top-down" hint to infer that `arg2` could be a fresh lifetime each time it's called: ``` let c: fn(&'a u32, &u32) = |arg1: &'a u32, arg2: &u32| { .. }; ``` joshtriplett: do we support using `'a` there to reference the parent lifetime? nikomatsakis: afaik. joshtriplett: do we still want the for syntax in order to be explicit even if in the future we'd prefer to be able to automatically handle it? pnkfelix: I think there are benefits to have an explicit syntax, but I'm always on the side of making things explicit nikomatsakis: I feel like it's useful to have a syntax even if you don't expect people to have use it nikomatsakis: my concern is that I don't see a way to *scale* this syntax to all the ways I could imagine ([link](https://github.com/rust-lang/rfcs/pull/3216#issuecomment-1064219041)) lokathor: could we introduce elision later on? nikomatsakis: it's an intentional subsetting to leave space for a future decision; the problem is that there are 2 or 3 things you might mean by it and it's not clear which is right. joshtriplett: I think given all this it's ok to move forward with `for`, even if this is not the "ultimate syntax" nikomatsakis: agree, I think I will resolve my concern ### "Tracking Issue for const offset_from (const_ptr_offset_from)" rust#92980 **Link:** https://github.com/rust-lang/rust/issues/92980 ### "Stabilize `let else`" rust#93628 **Link:** https://github.com/rust-lang/rust/pull/93628 nikomatsakis: how hard do people think the temporary lifetime stuff is? pnkfelix: no joshtriplett: do we have a specific test case with what we are trying to fix? pnkfelix: lcnr posted a playground, but it's not in the PR pnkfelix: right, I can make a table to try and summarize key cases. I just got nerdsniped. ### "Stabilize `let_chains` in Rust 1.62.0" rust#94927 **Link:** https://github.com/rust-lang/rust/pull/94927 ## Active FCPs ### "Tracking issue for `const extern fn` and `const unsafe extern fn`" rust#64926 **Link:** https://github.com/rust-lang/rust/issues/64926 ### "Always evaluate all cfg predicate in all() and any()" rust#94295 **Link:** https://github.com/rust-lang/rust/pull/94295 ### "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 ## P-critical issues None. ## Nominated RFCs, PRs and issues discussed this meeting ### "Tracking issue for Allow a re-export for `main` (RFC 1260)" rust#28937 **Link:** https://github.com/rust-lang/rust/issues/28937 joshtriplett: Does this need further discussion? nikomatsakis: I think this is all set, nobody has strong opinions about it, seems like it "might be nice". joshtriplett: Any objections to marking as "ready to stabilize"? ### "Allow `impl Fn() -> impl Trait` in return position" rust#93582 **Link:** https://github.com/rust-lang/rust/pull/93582 ```rust fn f0() -> impl Fn() -> impl Trait; // ^^^^^^^^^^^^^ new fn f3() -> &'static dyn Fn() -> impl Trait; ``` analogous to `T: Iterator<Item = impl Trait>`, which works today. pnkfelix: How does the `dyn` example work? nikomatsakis: it's equivalent to: ```rust type Alias = impl Debug; fn f3() -> &dyn Fn() -> Alias { if true { foo } else { bar } } fn foo() -> u32 { 22 } fn bar() -> u32 { 22 } ``` nikomatsakis: One question is about precedence of `+`: ```rust fn f0(&u8) -> impl Fn(&u8) -> impl Trait + '_; // what should this mean? fn f0(&u8) -> impl Fn(&u8) -> (impl Trait + '_); fn f0(&u8) -> impl Fn(&u8) -> impl (Trait + '_); // * niko finds these the clearest // vs fn f0(&u8) -> impl Fn(&u8) -> (impl Trait) + '_; fn f0(&u8) -> impl (Fn(&u8) -> impl Trait) + '_; // * niko finds these the clearest // would it not be this? fn f0(&u8) -> (impl Fn(&u8) -> impl Trait) + '_; ``` pnkfelix: suggestion: please specify both variants, in terms of what desired precedence is intended. nikomatsakis: `fn foo(x: &impl Fn() -> impl Debug + Send)` nikomatsakis: what I wanted form this meeting was agreement to go with "Require disambiguation" joshtriplett: "don't guess" seems like a useful language property: if it can be A or B, you don't just pick one. I like "nonassociative operators" in haskell: you *can't* do `x op y op z` without parentheses. We should apply this pattern elsewhere. mara: +1 pnkfelix: in the limit, lisp! joshtriplett: tempting to make `->` non-associative, but right-associative seems right, but the combination of it and `+` is sufficiently ambiguous... mara: it's a bit tricky, other languages with non-associativity is the property of a precedence level. We do want to support `a + b + c`, but don't want to support a combination of arrows and plusses. joshtriplett: yes, tricky. ### "Allow struct and enum to contain inner attrs" rust#84414 **Link:** https://github.com/rust-lang/rust/pull/84414 nikomatsakis: has anyone looked at this? seems straightforward. scottmcm: (from before) feels weird to do this after having removed it from match mara: seems weird to have them in places where we have comma separated things rather than semicolon separated things nikomatsakis: don't have a strong opinion, but would like to reach a decision, maybe Josh you'd like to move to close? joshtriplett: should I untag compiler first? pnkfelix: fine with me. joshtriplett: it would be nice if close didnt require fcp in the first place, since it's reversible. ## Nominated RFCs, PRs and issues NOT discussed this meeting ### "Lazy tait take two" rust#94081 **Link:** https://github.com/rust-lang/rust/pull/94081

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.