---
title: Triage meeting 2022-09-06
tags: triage-meeting
---
# T-lang meeting agenda
* Meeting date: 2022-09-06
## Attendance
* Team members: Niko, Felix
* Others: Mark
## Meeting roles
* Action item scribe: Felix
* Note-taker: nikomatsakis
## Announcements or custom items
### Cleaning up the above links
nikomatsakis: I'd like to cleanup the scheduled meetings + the pending lang team proposals. They're driving me bonkers. I will schedule some time for this and make some Executive Decisions.
joshtriplett: go for it
### Arbitrary downcasting
### Lang team governance, initiatives, oh my
- nikomatsakis plans to float a proposal for a new subteam (Lang Advisors) and a "path to membership"
- nikomatsakis + joshtriplett have been thinking about revisions to initiative system
- no detailed discussions at this time, just a heads up
zulip topic from early July: [membership criteria, path to membership](https://rust-lang.zulipchat.com/#narrow/stream/235524-t-lang.2Fprivate/topic/membership.20criteria.2C.20path.20to.20membership/near/288918237)
## Action item review
* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)
## Pending lang team project proposals
### "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
### "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
### "add `#[never_call]` attribute" lang-team#170
**Link:** https://github.com/rust-lang/lang-team/issues/170
joshtriplett: this is worth a look!
## 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
## RFCs waiting to be merged
None.
## Proposed FCPs
**Check your boxes!**
### "Rust Style Team" rfcs#3309
- **Link:** https://github.com/rust-lang/rfcs/pull/3309
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3309#issuecomment-1236096494):
> 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/rfcs/pull/3309#issuecomment-1236096488):
> Doing this half by hand and half with rfcbot:
>
> Lang team, shall we approve the creation of the Rust Style team?
>
> @rfcbot merge
>
> Even though per the previous commit rustfmt will no longer be a parent team of the style team, the style team will still have a close working relationship with the rustfmt team. So, rustfmt team (@calebcartwright and @ytmimi), do you also approve the creation of the Rust style team? (Please feel free to respond with either a comment confirming or a comment raising any concerns you may have.)
joshtriplett: RFC proposing to create a team under lang with cooperation and full support of rustfmt team to serve the function of old Rust style team, deciding what the rust style should be. rustfmt doesn't want this job.
nikomatsakis: planned lead and/or membership?
joshtriplett: calebcartwright to lead, me to be a member, along with Jane Lusby (yaahc) and compiler-errors. happy to add more people if people are excited about bikeshedding.
nikomatsakis: ok! I'll skim RFC. Does it lay out decision structure?
joshtriplett: combination of "in-person meetings" and big things via RFCs, or PRs to the style guide.
nikomatsakis: nice, I like that.
joshtriplett: idea is small things via style-guide and larger things via the old fmt-rfcs repository.
### "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:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * rust-reference (https://github.com/rust-lang/rust/issues/93333#issuecomment-1217057760)
>
> 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
joshtriplett: still an ICE being tracked down. Unless the ICE is fixed really soon this won't make 1.65.
pnkfelix: whoever filed that concern about consistency ought to resolve it. Oh! That's me!
joshtriplett: Now we need a "still ICE-ing" concern.
nikomatsakis desperately tries to think of a pun.
nikomatsakis: I feel we can let the FCP go, but we don't land the PR until technical issues are resolved.
pnkfelix: that's probably best.
nikomatsakis: maybe add a checkbox to the OP or something.
joshtriplett: ICE is [#99975](https://github.com/rust-lang/rust/issues/99975).
nikomatsakis: it'd be nice if GH had a "blocked on #123" mechanism.
### "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
>
> Concerns:
>
> * needs-exact-proposed-rule (https://github.com/rust-lang/rust/issues/99104#issuecomment-1209723811)
>
> 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
### "Commit to safety rules for dyn trait upcasting" rust#101336
- **Link:** https://github.com/rust-lang/rust/issues/101336
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/101336#issuecomment-1236012485):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [ ] @joshtriplett
> * [x] @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/101336#issuecomment-1236012468):
> OK, I've adjusted the proposal slightly so that the validity invariant is now word-aligned, non-null. This is consistent with other pointer-like values and offers us more room for future change if needed.
>
> As such, I am ready to ...
>
> @rfcbot fcp merge
nikomatsakis: I wanted to raise this.
* safety condition: `*const dyn Trait`
* validity condition: vtable must be a word-aligned, non-null pointer, consistent with `fn`
nikomatsakis: another way to say it is, as long as you cafefully control the code, you have to have a word-aligned, non-null pointer for the vtable.
joshtriplett: what do we gain by saying it can't be null?
nikomatsakis: we gain a niche -- oh, and it's more consistent. we could permit null (as described in the doc).
joshtriplett: to clarify, if I have a union that contains a wide pointer
nikomatsakis: So for example...
```rust
union Foo {
p1: *const dyn std::fmt::Debug,
p2: [usize; 2],
}
```
... as long asy ou don't access the `p1` field, you're fine no matter what. But if you access `p1` (even from unsafe code), then `p2[1]` must be word-aligned, non-null. And if you upcast/release-to-safe-code/method calls, then it must further be an actual vtable.
joshtriplett: what would go wrong if it were null?
nikomatsakis: technically UB, but it would be most observable with `Option`.
scottmcm: even without the field `p2` the validity invariant would be suppressed unless it were accessed.
joshtriplett: and I could use `MaybeUninit` if I wanted to.
joshtriplett: does seem like a tiny bit of a footgun that I think that has a `*`, as opposed to an ampersand, has an invariant.
tmandry: is it an option to say that the upcasts are invalid in safe code?
nikomatsakis: it's complex. I think better would be to say that metadata could be
joshtriplett: no, I think having a niche is important here; it's worth having validity invariants.
nikomatsakis: I agree that either word-aligned or word-aligned-not-null is the right choice. Not sure how to decide between them, but I was pushed over line by future compatibility.
joshtriplett: though in practice people may be relying on `0` being a niche already
scottmcm: note that the data pointer doesn't have an invariant
joshtriplett: in particular, dyn is the thing adding the invariant, not `*`
nikomatsakis: the invariant on pointer metadata is just distinct from the invariant on the data, it is something people will have to get used to
scottmcm: do we have a slice invariant?
nikomatsakis: we could've said it has to be `isize`, not sure.
nikomatsakis: another option would be to not settle it and leave it to a future UCG spec, but I think I'd like to start settling these questions.
joshtriplett: we've been arguing about it long enough and while I was originally concerned about `*` having any conditions, I think if people can use it in a union, that's fine
scottmcm: also it need not be derefernceable, just aligned
joshtriplett: meaning what exactly?
scottmcm: the validity invariant is just that it's aligned, it doesn't have to be a valid vtable
joshtriplett: not unless you actually cast it
scottmcm: yes
joshtriplett: I've gone back and forth about having an if-not-null in dyn upcasting so you can use null, but I can live without it
pnkfelix: in a compiler-team meeting, it became obvious that the consteval rules are stricter, I'm wondering if that matters here
nikomatsakis: I remember Ralf talking about how to define what is a valid vtable in miri, I think the idea was to leverage custom allocators so vtables (along with other statically allocated things) act like something that's from a distinct allocator from normal memory
scottmcm: validity invariant isn't usually the hard part for miri anyway
nikomatsakis: ralf didn't raise any concerns from this perspective, also
tmandry: this will mean that if you have a `*const dyn` lying around, and you don't have a vtable handy, you have to use an `Option`...
nikomatsakis: ...or maybe-uninit, if you can't track it some other way.
tmandry: could be hard to track whether any code does any sort of upcasts
nikomatsakis: my take is that if you're keeping the pointer around for a long time, you probably want a maybe-uninit anyway
tmandry: specifically for null pointers, we're pushing people towards options. Might be less convenient to use in unsafe code, but that is a choice.
scottmcm: I wish we could get rid of nullable raw pointers overall and just made `Option` easier to use.
joshtriplett: I'm all for having some kind of raw references.
nikomatsakis: to answer tyler, I think it's just true that if your `T` is not sized, and you need a maybe-null raw pointer, you should use `Option`.
joshtriplett: are there more concerns needed to address this question?
scottmcm: I was definitely talking future, not now
tmandry: I was just pointing out that it pushes the way people write unsafe in a particular direction, just something to consider
scottmcm: also doesn't solve "how do you get a null pointer of a dyn type"?
nikomatsakis: yeah, you type `None`. There's only so much value to fine-tuning the validity invariant; I think I'd rather not add a sentinel value, because it would add overhead to the main path, and I'd rather folks write `Option`.
tmandry: My concern is that it makes unsafe code a bit harder to write, and it's already hard, so +1 I guess for making option easier to use.
scottmcm: We have some options available to simplify things by using custom impls in libstd (I *think* this is what scott was saying? --nikomatsakis)
## Active FCPs
### "De-RFC: Remove type ascription" rfcs#3307
**Link:** https://github.com/rust-lang/rfcs/pull/3307
### "Tracking issue for `..X`, and `..=X` (`#![feature(half_open_range_patterns)]`)" rust#67264
**Link:** https://github.com/rust-lang/rust/issues/67264
### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727
**Link:** https://github.com/rust-lang/rust/issues/74727
### "Stabilize generic associated types" rust#96709
**Link:** https://github.com/rust-lang/rust/pull/96709
### "Consider `#[must_use]` annotation on `async fn` as also affecting the `Future::Output`" rust#100633
**Link:** https://github.com/rust-lang/rust/pull/100633
### "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
### "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
### "RFC: Statics in patterns" rfcs#3305
**Link:** https://github.com/rust-lang/rfcs/pull/3305
nikomatsakis: I left a comment. Inclined to fcp close at the moment for the reasons I stated.
joshtriplett: I think the right way is to fcp close. We can always change our minds at some future point.
pnkfelix: I'll propose closing it.
### "Simple postfix macros" rfcs#2442
**Link:** https://github.com/rust-lang/rfcs/pull/2442
joshtriplett: Don't want to create a long discussion, just want to ask the question -- I know Felix took a look at this after I added the auto-ref mechanism, which I can do, but I wanted to find out if anybody else had thoughts or feedback. Where are we at -- needs more docs, or if people don't want it.
scottmcm: I've not looked at it recently, so this might be naive, but it definitely hinges on "what is this auto-ref mechanism and how well does it fit with other things". It's a "place-forwarding system"?
joshtriplett: We could theoretically make it available as a mechanism on its own, but right now it's just something we use for the desugaring. Same one that closures use for their auto-ref mechanism -- RFC...?
nikomatsakis: RFC 2229!!
joshtriplett: ...that's the one. The way to say "compiler please figure out what is needed". So you can do `something.some_field.postfix_macro!()` that won't move the field (unless it has to) but rather would use a reference.
scottmcm: the magic owning reference?
joshtriplett: "however much of a reference you can get away with and still do the operation in the macro".
joshtriplett: originally I had the macro declare what you wanted, but that was terrible for ergonomics (You'd have to write `(&foo).postfix!()`). Changing that so that it autorefs provided the same behavior you'd get when you `.` a method
nikomatsakis: did you discuss the idea of explicitly writing `&self`, `&mut self`, same as any other method? Not clear why it should behave differently from other methods.
joshtriplett: could still write it explicitly using a let-binding, same way you can in a closure, just not sure we need to mandate it.
scottmcm: distinction between the ref and mut feels odd to me at a token level.
joshtriplett: what distinction do you mean?
scottmcm: putting sort of a type question at the token level. Feels odd to me that my postfix macro can't expand to a method call. At the token level, I feel like if I do `.foo!()` I could expand that to `.foo()` and that should work, but if I have to say whether it's ref-self or ref-mut-self, it might not work anymore?
joshtriplett: I see what you're saying, with current proposal, you can just have it figure out the right thing, but if you had to explicit write it, you'd have to match whatever the method needed.
nikomatsakis: let's discuss async.
joshtriplett: yes.
scottmcm: comes down to me about the details of the autoref mechanism, maybe they're addressed, I haven't looked.
joshtriplett: I believe I had a reference in the RFC saying "we might want this elsewhere but not trying to propose a mechanism there right now".
### "De-RFC: Remove type ascription" rfcs#3307
**Link:** https://github.com/rust-lang/rfcs/pull/3307
nikomatsakis: removed I-lang-nominated here
### "Rust Style Team" rfcs#3309
**Link:** https://github.com/rust-lang/rfcs/pull/3309
nikomatsakis: removed I-lang-nominated here
### "Tracking issue for dyn upcasting coercion" rust#65991
**Link:** https://github.com/rust-lang/rust/issues/65991
nikomatsakis: removed I-lang-nominated here, left a comment
### "Tracking issue for `std::hint::black_box`" rust#64102
**Link:** https://github.com/rust-lang/rust/issues/64102
scottmcm: my intution is that black-box from a lang level is under hint because it's allowed to do absolutely nothing.
joshtriplett: I think from a lang POV we should say it's up to libs with what to call it, but we're ok with a thing like this existing and committing to making it work -- for some value of work, it will always be best effort.
scottmcm: I think from a lang perspective, we're not committing to it working at all, if anything it should be a compiler nomination, whether they're happy to support some kind of best-effort here.
joshtriplett: that makes sense
scottmcm: nominate for compiler then?
joshtriplett: I think we should say it's up to libs whether they want further confirmation.
nikomatsakis: yes, just say "For our part, we are happy, but @rust-lang/t-compiler may have concerns".
### "Regression transmuting `RwLockReadGuard<T: ?Sized>`." rust#101081
**Link:** https://github.com/rust-lang/rust/issues/101081
nikomatsakis: we discussed this before, does it still need to be nominated, I forget the status?
simulacrum: I think the question is rather broad and might be more types team.
Mara's comment:
> So to clarify, the question for the language team:
>
> - Should `std::mem::transmute<Something<'a>, Something<'b>>(..)` always be accepted (even if `Something<'_>` isn't repr(anything))? It's not uncommon to use `transmute` to unsafely change a lifetime, but today that sometimes results in an error, depending on some details of `Something`: see [above](https://github.com/rust-lang/rust/issues/101081#issue-1353027423).
nikomatsakis: ok, toss to types team, it's pretty niggly.
### "Tracking issue for RFC 2383, "Lint Reasons RFC"" rust#54503
**Link:** https://github.com/rust-lang/rust/issues/54503
simulacrum: blocked on maybe a design meeting? need more time than we have in this meeting.
### "`#[track_caller]` erroneously points to macro call" rust#95152
**Link:** https://github.com/rust-lang/rust/issues/95152
nikomatsakis: Removing nomination, we gave our opinion, is any further action needed? e.g., close issue?
simulacrum: seems like next step would be someone implementation.
### "Implement pointee metadata unsizing via a TypedMetadata<T\> container" rust#97052
**Link:** https://github.com/rust-lang/rust/pull/97052
### "Loosen shadowing check inside macro contexts (attempt 2)." rust#100453
**Link:** https://github.com/rust-lang/rust/pull/100453
nikomatsakis: petrochenkov is against it. I think I agree that I'm not inclined to make small-time changes rather than a more holistic fix for hygiene.
pnkfelix: fixing this problem is worth it, yes.
simulacrum: the concrete problem is probably fixable?
pnkfelix: you can always rename, but you shouldn't *have* to. Is argument you're making that you have to be aware of items that might be in scope?
simulacrum: seems like general problem exists and
nikomatsakis: basically, this is a known shortcoming of our hygiene system, and as a result, we should at least put some `_` in our names to make conflicts less likely?
## Nominated RFCs, PRs and issues NOT discussed this meeting
### "let_chains desugaring is wrong" rust#100513
**Link:** https://github.com/rust-lang/rust/issues/100513
### "repr(transparent) could accept singleton ZST with alignment > 1." rust#100954
**Link:** https://github.com/rust-lang/rust/issues/100954
Sign in with Wallet
Connect another wallet