---
# System prepended metadata

title: Triage meeting 2022-03-22
tags: [triage-meeting]

---

---
title: Triage meeting 2022-03-22
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-03-22

## Attendance

* Team members: nikomatsakis, pnkfelix, Josh, Taylor
* Others: Lokathor, David Barsky, skippy

## Meeting roles

* Action item scribe: pnkfelix
* Note-taker: nikomatsakis

## Scheduled meetings
-  "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94) 
-  "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97) 
-  "Dyn upcasting, safety considerations" [lang-team#119](https://github.com/rust-lang/lang-team/issues/119) 
-  "Const eval overview" [lang-team#131](https://github.com/rust-lang/lang-team/issues/131) 
-  "Lint policy" [lang-team#132](https://github.com/rust-lang/lang-team/issues/132) 
-  ""RPITIDT"" [lang-team#144](https://github.com/rust-lang/lang-team/issues/144) 

## Announcements or custom items

### Types team update

nikomatsakis: Just thought people might find these things interesting

* [draft RFC available](https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/types.20team.20RFC)
* [deep dive chat about formality](https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/deep.20dive.202022-03-18.3A.20intro.20to.20formality)
* https://hackmd.io/IUxTu4dJTP2oEnjHfB69KA?edit

### Lang team roadmap publication

* [New draft available](https://hackmd.io/bl_kTwS9Q4yFkf_XrVEPtQ?view)
* [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/318377-t-lang.2Froadmap-2024)

joshtriplett: Do we feel ready to make an FCP proposal for this?

joshtriplett: Would best way be a PR to lang-team repository with an FCP, and then an Inside Rust blog post?

joshtriplett: Or are there substantial concerns to raise before FCP?

nikomatsakis: maybe replace this page with the blog post :)

https://lang-team.rust-lang.org/initiatives/priorities.html

nikomatsakis: Or just delete that page in favor of the roadmap

pnkfelix: I basically trust the two of you to have drafted something that makes sense; I've skimmed it a few times since we had our last deeper discussion. Only real question is whether there is any value in having a sync meeting to discuss it, or just say "no, we'll either async review it". Some of the lang team members aren't present in this meeting so we can't get their voice into what I'm saying.

joshtriplett: Have 4/5 at the moment. 

pnkfelix: Oh!

cramertj, sweetly: "Hi Felix"

pnkfelix: OK-- well, is there value in a forced reading? I'm fine with async acceptance.

joshtriplett: I think it is appropriate to have an FCP to make sure it's what we'd like to officially endorse. I appreciate the trust you are expressing but I think it's appropriate to get full team signoff.

nikomatsakis: Are you suggesting we should ensure all 5 boxes are checked?

joshtriplett: No, I'd just want to follow the normal RFC process and have no objections.

nikomatsakis: I'd rather not block on a synchronous meeting.

pnkfelix: I think you should put a date for when you want people to respond by, to try and get a forcing function.

joshtriplett: OK, I'll take the action item on that.

joshtriplett: Oh, also, there's a t-lang/roadmap-2024 stream for discussion here.

### style team revival

joshtriplett: Folks during rustfmt are finding themselves in the position of having to decide style. They'd prefer to have policy be made by a team. I think that makes sense. Calebcartwright is interested in working on the style team issues; I am as well. I was a member of the style team back in the day. I see a lot of value in having a dedicated team for this. Doesn't need to be a weekly meeting like it used to be -- seems like a good idea. Any objections? Where should it be chartered? Who else might be interested?

nikomatsakis: (a) good idea (b) lang (c) I have no idea

joshtriplett: I agree with lang since it's mostly focused on lang formatting. Jane, Mara, do you think this has libs implications? 

yaahc: I think it's mostly lang. Libs implications in terms of how we *use* the features, but doesn't feel like it needs to be cross-team specifically.

joshtriplett: yeah, I was thinking mostly of who would approve the charter.

mara: :+1: 

joshtriplett: ok, we've settled (a) and (b), scottmcm, you had a hand up earlier?

*hilarity around being muted ensues, scottmcm drops*

joshtriplett: anybody on this call excited about being on the ~~bikeshed~~ style team?

lokathor: yeah, I'll do that

nikomatsakis: oh dear god no

joshtriplett: that's 3 (caleb, josh, lokathor --ed), sounds good.

## 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

joshtriplett: continued large and expansive discussion here on Zulip. Hoping that we will eventually get this sorted, but it kind of grew and mutated, now also an ongoing discussion about unsafe code guidelines, pointers, providence, CHERI, etc. CHERI of course is one of the platforms where pointers are 128 and size_t is not. That part of the discussion doesn't have to be resolved to settle the short term question of whether `usize` is always `size_t`. I think that could be done, possibly over an edition boundary, but it doesn't quite feel like the right time to reach a decision. I think we might have consensus amongst the team, not sure yet, but I'm tracking the zulip discussion.

### "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

nikomatsakis: what about this one? 

joshtriplett: I think people want it, but I'm not sure if it's still live. Updated only about a month ago.

nikomatsakis: I can follow up with Jack and see if he's still interested in this.

### "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: I wanted to call attention the fact that this was seconded! Also skippy is here!

skippy: Hi!

joshtriplett: I think they've been working on adding this to the compiler, too. 

skippy: Do have some questions about traits code.

joshtriplett: Getting questions answered before a full draft is not a bad thing -- I wonder if we might have a team for that -- 

nikomatsakis: Drop in #wg-traits if you like, but I'm surprised you're in that code...

skippy: Fn traits---making all that work--- pretty much melted my brain.

nikomatsakis: Oh dear.

### "extern macro!(ABI) fn" lang-team#151

**Link:** https://github.com/rust-lang/lang-team/issues/151

Allows people to extract cases of ABIs into a macro. e.g.

```rust
extern foo!() {
    
}
```

Looks like Niko has seconded.

nikomatsakis: One question is if we feel an RFC is needed. I think it could get by with a tracking issue, PR, and a write-up.

joshtriplett: Is this insta-stable?

nikomatsakis: No.

pnkfelix: there was some resistance from petrochenkov saying, in essence, that this is a heavy-weight option compared to the problem it's solving. I think they were just saying "why don't we just adopt some semantics that would make us compatible with what windows does". Want to convey that there is at least some resistance from someone.

joshtriplett: For context, windows has a bunch of ABIs (fastcall etc). On 64-bit windows, in order to make code for 32-bit windows capable of being recompiled, they effectively made all those calling conventions no-ops. There was a proposal that we do the same, allow parsing things like fastcall on 64-bit windows and just ignore it and pass it through like the windows compiler would. Versus doing this by selecting via macros.

pnkfelix: In particular, we already do that for fastcall, but thiscall is a special case for historical reasons, or maybe lack of historical reasons.

nikomatsakis: I agree that we should match behavior of the windows compiler if we can.

joshtriplett: They had a big pile of 32 bit code, we don't have that constraint, so it's not obvious whether we should do that.

Lokathor: I think that having Rust code binding to C code look like the C code. If C code is expected to discard it, Rust code should do that too.

joshtriplett: Yes, I wasn't saying we shouldn't do this, but I think we shouldn't necessarily treat it as automatic to do it just because C does. Don't want to set precedent that we make decisions motivated by C legacy code. If it's a decision for convenience of new code, we should consider that.

nikomatsakis: It doesn't feel like legacy code is the motivation so much as parity with C code.

cramertj: Isn't this "far away" from whether you should be able to use macros in ABI position?

pnkfelix: There may be other reasons to support this beyond this one use case. 

joshtriplett: As a general rule I would want to support macros anywhere that we can.

nikomatsakis: yes-- I think my response to petrochenkov is "why not both".

joshtriplett: Yes, it's a valid concern, but if there are uses beyond this use case. There was a comment on Rustacean Station that was something we should pay attention to, "macros are a wonderful tool for language and library design, but there's something unusual about language shipping things in macro form; you own the language, you can make it better". I kind of agree with that. If we were adding this just to workaround not having a feature, maybe we should just make it better.

cramertj: To bring this back to the core question, what happens today if you try and do this, can you not write a macro there at all? There are other things you can put between `extern` and `fn` besides an ABI, right? I guess `unsafe` comes first?

pnkfelix: I think you have to put ABI after...? Well, I don't remember.

cramertj: Well, you can just say `extern fn` foo...

Lokathor: ...and it's implicitly C...

cramertj: ...so my question is, what if it generated things beyond the ABI string

pnkfelix: e.g. the entire fn string

cramertj: yes, or one of the other keywords (async, const, etc). I think I would not expect that it can generate *some* of the things from that position and not others.

Lokathor: true. 

pnkfelix: yes. Question being raised then: is this proposal to permit *just* an ABI, or does it permit other things? Any keyword, whole function definition? Sounds like something that needs to be pinned down.

cramertj: That is my question. If you could have a macro invocation following extern, I'd like it to be at least somewhat intuitive what it could expand to. It's surprising to me if it can only generate an ABI string and nothing else. 

pnkfelix: I had opposite reaction, to be honest.

cramertj: what would you expect from this?

```rust
foo!() fn()
```

pnkfelix: arbitrary macro followed by `fn `... probably a separate item

scottmcm: what seems different to me is that it's `extern foo!()`, which disambiguates it a little bit.

cramertj: I see, so the extern feels to you like it has an implicit precedence of capturing the thing that follows it. I don't have that intution, but I can believe that others do.

scottmcm: I'm not sure that I have that intuition, but that is what makes it different from other tokens.

pnkfelix: Question is whether you can have other things after `extern` besides ABI and `fn` -- if parser allows other things after extern, that does change the story.

cramertj: I think that it seems sort of unique to have `extern foo!()` "capture" the `foo!()`.

scottmcm: Analogy: `pub(macro!()) fn foo()` might be fine even though `macro_including_the_pub!() fn foo()` isn't.

joshtriplett: Does this already work? If so, I think that'd be sufficient and preferable.

```rust=
#[some_proc_macro_setting_extern_abi(...)]
fn xyz() {
    ...
}
```

nikomatsakis: yes, you can certainly do that

joshtriplett: ok, so if there's an established way to do this, then would it make sense to say "that is the solution rather than filling in a random token in this particular place". I'm feeling more sympathy for petrochenkov's position here.

nikomatsakis: this is sort of the "general answer", because you can always pull a macro out

joshtriplett: it's not always satisfying since a top-level parser transformer is more annoying, but for this particular case, it's placed in the exact place that ABI would go

joshtriplett: I do wish you could write attribute macros with macro rules.

nikomatsakis: I think cramertj convinced me that this isn't worth the trouble. That said, in general macros don't "pop out" from the thing you are parsing.

Lokathor: instead of this being a macro, why not some way to remap ABI strings?

nikomatsakis: but why?

Lokathor: solves this use case.

joshtriplett: feels like an impl detail that we used a string.  

joshtriplett: Sounds like we're kind of reaching a consensus leaning towards "closing this".

joshtriplett: Objections to that consensus? Volunteer to write it up?

nikomatsakis: I'd write it up. (Lokathor, we could discuss that separately, but I generally think a proc macro is good enough for that.)

joshtriplett: side note but I want to be able to use a macro-rules macro as an attribute. It'd be nice if you didn't have to use proc-macros for that.

pnkfelix: yes, I don't think they'd be happy with proc macro, providing a 3P crate that just does it would be ok too.

## PRs on the lang-team repo

None.


## RFCs waiting to be merged

None.


## Proposed FCPs

**Check your boxes!**
### "Add the partial-closure-args RFC." rfcs#2956

**Link:** https://github.com/rust-lang/rfcs/pull/2956

### "New Rust attribute to support embedding debugger visualizers" rfcs#3191

**Link:** https://github.com/rust-lang/rfcs/pull/3191

### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

**Link:** https://github.com/rust-lang/rfcs/pull/3216

### "Allow struct and enum to contain inner attrs" rust#84414

**Link:** https://github.com/rust-lang/rust/pull/84414

### "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

### "Fix constants not getting dropped if part of a diverging expression" rust#94775

**Link:** https://github.com/rust-lang/rust/pull/94775

### "Stabilize `let_chains` in Rust 1.62.0" rust#94927

**Link:** https://github.com/rust-lang/rust/pull/94927



## Active FCPs
### "Lazy tait take two" rust#94081

**Link:** https://github.com/rust-lang/rust/pull/94081

### "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

barsky: Is dtolnay involved in this?

nikomatsakis: I don't know! Just ping him!

[dbarsky messages dtolnay about this]

### "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

### "extern macro!(ABI) fn" lang-team#151

**Link:** https://github.com/rust-lang/lang-team/issues/151



## P-critical issues

None.




## Nominated RFCs, PRs and issues discussed this meeting

### "Clarify guarantees provided by repr(packed)" reference#1163

**Link:** https://github.com/rust-lang/reference/pull/1163

joshtriplett: nikomatsakis said he likd this, seemed reasonable... 

nikomatsakis: this seemed very minor. Not sure if it needs an FCP, seemed like a clarification.

joshtriplett: when we're expanding guarantees to include things we've assumed, I think it's reasonable to FCP. Not so heavy weight.

nikomatsakis: I learned something, in any case, I'd forgotten you could specify an alignment with `padding`.

### "Specify guarantees for repr(rust) structs" reference#1152

**Link:** https://github.com/rust-lang/reference/pull/1152

joshtriplett: This actually changes the statement of tuples having zero guarantees -- and a few other things.

nikomatsakis: I wonder how this compares to what we wrote up in the unsafe code guidelines. I should compare.

nikomatsakis: (sounds of document perusal ensue) https://rust-lang.github.io/unsafe-code-guidelines/

> In general, an anonymous tuple type (T1..Tn) of arity N is laid out "as if" there were a corresponding tuple struct declared in libcore.
> 
> ```
> #[repr(Rust)]
> struct TupleN<P1..Pn:?Sized>(P1..Pn);
> ```
> 
> ...As discussed below, this generally means that the compiler is free to re-order field layout as it wishes....

nikomatsakis: I would like to see the UCG text move into the reference bit by bit. 

### "Implement `Clone` for generators" compiler-team#494

**Link:** https://github.com/rust-lang/compiler-team/issues/494

joshtriplett: This needs lang review. Primarily a libs thing--whatever generator type is needs to have clone support-- but OTOH this has implications for how generators act in the language as a language construct. Anyway we may to take a look.

nikomatsakis: tl;dr, we currently allow closures to be clone if their contents are clone, this would extend to generators, it seems fine to me, I think this should be FCP'd when it lands, I don't think we need to be sticklers around having a lang team proposal or anything.

nikomatsakis: we had an RFC for the closure case, this seems like a small extension to that.

joshtriplett: being consulted seems fine.

pnkfelix: has someone reviewed the Zulip thread? I see lcnr is being somewhat resistant, not sure why. Seems like they think it's ok now, but I'd want to know that somebody read it.

nikomatsakis: I'll write the comment.

### "Check if call return type is visibly uninhabited when building MIR" rust#93313

**Link:** https://github.com/rust-lang/rust/pull/93313

joshtriplett: Does someone know what this is about and what we want to do about the lang team question? This is accepting more code than we did before, hence the need for lang team approval.

(some discussion ensued)

nikomatsakis: Will tag T-lang and FCP

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

**Link:** https://github.com/rust-lang/rfcs/pull/3216

### "Allow `impl Fn() -> impl Trait` in return position" rust#93582

**Link:** https://github.com/rust-lang/rust/pull/93582

### "Stabilize `let_chains` in Rust 1.62.0" rust#94927

**Link:** https://github.com/rust-lang/rust/pull/94927



