---
title: Triage meeting 2022-09-20
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-09-20

## Attendance

* Team members: nikomatsakis, pnkfelix, scottmcm
* Others: simulacrum

## Meeting roles

* Action item scribe:
* 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)
- "Return Position impl Trait in dyn Trait ("RPITIDT")" [lang-team#144](https://github.com/rust-lang/lang-team/issues/144)

## Announcements or custom items

### Simplified initiative procedure

nikomatsakis: I've been working on docs for a simplified initiative procedure. This comes out of discussion with Josh. I pushed a [rendered copy] here. I plan to open a PR after this meeting to FCP.

[rendered copy]: http://smallcultfollowing.com/lang-team-2022-09-20-preview/how_to/propose.html

I also plan to open a separate PR with documented criteria for membership that I floated some time back.

Major points discussed in meeting:

* scottmcm points out that an alternative to being experienced is to actually do the work in a branch and open the PR, that can be a way to provide evidence that your serious.
* scottmcm would like "small changes" that can be done in a PR as a part of the process, this is perhaps implied by the "tweak to an existing feature" edge.
* some discussion about whether an RFC is always required. Consensus of meeting was that our preference is to say that RFC is only not required for small and uncontroversial changes, and that RFCs should be required most of the time.
* Josh: disagreeing with that; RFC should be required even for small changes, unless it's just an FCP reviewing an obvious extension to an existing feature, e.g. "allow existing RFC X to work on target Y or scenario Z" or similar.

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

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

nikomatsakis is supposed to read this.

## RFCs waiting to be merged
### "Rust Style Team" rfcs#3309

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

FCP completed. Somebody should merge it!

*awkward silence*

pnkfelix volunteers! :tada: And Josh in text! :tada: :tada: Josh wins.

## Proposed FCPs

**Check your boxes!**
### "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

Concern resolved! Going into FCP.

### "Stop using `Reveal::All` before borrowck" rust#101478

- **Link:** https://github.com/rust-lang/rust/pull/101478
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/101478#issuecomment-1249693297):
> Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @compiler-errors
> * [ ] @cramertj
> * [ ] @jackh726
> * [ ] @joshtriplett
> * [x] @lcnr
> * [ ] @nikomatsakis
> * [ ] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @spastorino
>
> 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/pull/101478#issuecomment-1249693270):
> I lowered some of the changes to a future compat lint which should hopefully allow us to merge this PR quickly without figuring out our exact goals for opaque types.
>
> ---
>
> This pull request changes the compiler to stop using `Reveal::All` at any point until `borrowck` is completed. Using `Reveal::All` means that it is possible to inspect
> - the underlying type of opaque types
> - the value of a "defaulted" associated item (requires `feature(specialization)`)
>
> In cases where this is known to break existing code, we retry the failing code with `Reveal::All`, emitting a future compatibility lint in case that succeeds. The cases where we emit a future compatibility lint are const evaluation for type system constants and `transmute` checking. **We currently do not retry for patterns, this is a breaking change, even if not discovered using crater.** See `in-ctfe/match-arm-exhaustive.rs` for an example. In case this causes an actual regression, we could extend the future compatibility lint to this area as well.
>
> This PR is necessary as using `Reveal::All` before `borrowck` is incorrect and blocks work on implied bounds. Even if we want to fully embrace opaque types in these places - which is not trivial, see https://github.com/rust-lang/rust/pull/101478#issuecomment-1246610070, the approach then should not use `Reveal::All`. So even then, this PR will be "correct". I do not want to wait with my implied bounds work until this is figured out.
>
>
>
> A crater run found 2 impacted crates:
>
> ## [`mijit`](https://github.com/apt1002/mijit/)
>
> Transmute in a test between an opaque type and the underlying concrete type. Opened PR fixing this in https://github.com/apt1002/mijit/pull/51.
>
> ## [`name-it`](https://github.com/GoldsteinE/name-it)
>
> This crate cannot really be fixed to avoid the lint, as it [fundamentally requires this pattern](https://github.com/GoldsteinE/name-it/blob/47544a062a950279fc49c8c3832b7b8e13febb8d/src/lib.rs#L104-L114):
> ```rust
> use std::mem;
> fn returns_opaque() -> impl Sized {
> 0u8
> }
>
> struct NamedOpaqueType {
> data: [mem::MaybeUninit<u8\>; size_of_fut(returns_opaque)]
> }
>
> const fn size_of_fut\<FUT\>(x: fn() -> FUT) -> usize {
> mem::size_of::\<FUT\>()
> }
> ```
> @rfcbot fcp merge

There is ongoing discussion but we are not covering it in detail in this meeting.

### "Allow transmutes between the same types after erasing lifetimes" rust#101520

- **Link:** https://github.com/rust-lang/rust/pull/101520
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/101520#issuecomment-1252016268):
> Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @compiler-errors
> * [ ] @cramertj
> * [x] @jackh726
> * [x] @joshtriplett
> * [x] @lcnr
> * [ ] @nikomatsakis
> * [x] @oli-obk
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @spastorino
>
> 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/pull/101520#issuecomment-1252016235):
> transmuting between (generic) types is only allowed for specific subsets of types. Usually this means that you can transmute between types where the sizes are known (e.g. pointers) or structs of a single field of such a type.
>
> The problem with those rules is that you can easily end up in a situation where `transmute<Foo<'a, T>, Foo<'b, T>>(x)` is rejected, because there are some non-zst fields:
>
> ```rust
> struct Foo<'a, T: ?Sized>(&'a T, i32);
>
> fn foo<'a, 'b, T: ?Sized>(x: Foo<'a, T>) -> Foo<'b, T> {
> unsafe { std::mem::transmute(x) }
> // ^ only an error if the `i32` field is there, otherwise compiles fine
> }
> ```
>
> I propose to relax the rules on transmutes and allow transmutes between types that are equal (ignoring regions). This means we lock ourselves into a world where we can never use specialization on lifetimes to change types. As far as I can tell this would be unsound for other reasons anyway, so it's not a loss.
>
> @rfcbot merge

nikomatsakis: cementing the idea that the size/layout of a type is not affected by lifetimes, I don't really see a reason *not* to do this, thoughts?

simulacrum: maybe we can add something that clarifies that this is not necessarily sound? Maybe a not to the docs of transmute?

joshtriplett: Notable issue raised on the thread: this closes off future ability to specialize on lifetimes. That seems acceptable though.

pnkfelix: isn't that orthogonal?

scottmcm: if you can specialize in a way that gives you an associated type that you put in your layout -- I don't see how that ever possibly work with reborrows.

nikomatsakis: I feel like we couldn't specialize on lifetimes anyway because of inference.

joshtriplett, quoting oli: "this means we lock ourselves into a world where we can never use specialization to change types", but that seems fine.

scottmcm: it's true, we can potentially find a way to specialize behavior, if anybody finds a way to fix the very complicated problem.

nikomatsakis: it's also true that it's not totally impossible to add future changes, e.g., could error after monomorphization or just declare it UB.

scottmcm: this does mean that changing this to a "const check" (e.g., if sizeof A == sizeof B) is probably harder, as opposed to the special compiler behavior.

nikomatsakis: why is it harder exactly?

scottmcm: this has always allowed generic types...?

nikomatsakis: can't transmute from T to U, just from `*T` to `*U`

nikomatsakis: I think it's already the case that we are checking that they have the *same* size, not that we can compute size statically, but I'm not entirely sure.

scottmcm: seems like it'll be complicated if it's complicated and that's ok.

nikomatsakis: you could ping oli on that point, he would know better.

### "Stablize `trait_upcasting` feature" rust#101718

- **Link:** https://github.com/rust-lang/rust/pull/101718
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/101718#issuecomment-1251188553):
> 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
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * doc-pr (https://github.com/rust-lang/rust/pull/101718#issuecomment-1251189105)
>
> 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/101718#issuecomment-1251188519):
> @rfcbot fcp merge
>
> Now that the FCP in https://github.com/rust-lang/rust/issues/101336 has ended, I'm going to move to stabilize dyn upcasting. @crlf0710 has provided a [stabilization report here](https://github.com/rust-lang/rust/pull/101718#issuecomment-1244925635).

nikomatsakis: there is a reference PR, but I haven't.

simulacrum: did we have an RFC?

nikomatsakis: not that I know of, I always considered this a bug, not an intentional "feature", but it's a good point.

joshtriplett: I was assuming there would be an RFC. (Josh raised a concern.)

simulacrum: Feels big enough to me that it's not a tweak.

scottmcm: To what Josh mentioned in text, there were reasonable choices to be made in this, right? e.g., what exactly can you upcast to?

nikomatsakis: You can upcast to any supertrait, but not combinations of traits, that's an orthogonal feature.

simulacrum: There was a decision around the unsafe rules.

nikomatsakis: Yes, that was a discussion there, but I wouldn't probably want to settle that in an RFC anyway. But I don't mind authoring an RFC, I think this is something an ordinary user would want to know about.

*nikomatsakis canceled FCP.*

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

(none yet, move things from the section below as they are discussed)

### "Simple postfix macros" rfcs#2442

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

simulacrum: We discussed this a week or two back and the goal was mainly to bring it to attention.

nikomatsakis: I recall that too, let's unnominate!

joshtriplett: :+1:

### "Add a new syntax to declare that a trait must always be object-safe" rfcs#3022

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

scottmcm: This is an old RFC, as I recall. Approaching two years. I wanted to bring it up mostly as a "let's try and make progress in some direction".

nikomatsakis: I'm in favor of this concept. One thing that seems relevant is that I think we are going towards a direction where `dyn Trait` doesn't necessarily implement `Trait`, in which case the importance of dyn safety is lowered.

scottmcm: Seemed like a good example of a pattern that we should make more first-class.

nikomatsakis: I'm still in favor, but another interaction is that if we did something like `dyn*` (which merits *much* broader discussion) it would expand the set of things that are dyn safe.

pnkfelix: One question, why not use attributes? I see it was alluded to you.

scottmcm: I think it just seemed like the right idea given that we have the keyword anyway.

nikomatsakis: One good reason for accepting this RFC is that some of the soundness fixes work much better if people *opt in* to dyn safety, beacuse there are limits we'd like to enforce on impls, but only if the trait must be dyn safe. Right now we don't know if the trait was meant to be dyn safe or not!

scottmcm: There's a nice edition path, though it's not discussion in the RFC.

nikomatsakis: My last hot-take is that I think dyn trait should probably be the default unless you opt out.

pnkfelix: bikeshed syntax for opt-out: `static trait Trait { }`

pnkfelix: The RFC as written doesn't include the text about soundness, right? I was in favor of the attribute approach until Niko's comment, if it's going to impose limits on other impls, then I'm in favor of using `dyn trait Trait { ... }`.

nikomatsakis: One thing I don't know is what we would do with all the traits that exist today. It probably is a good idea to revisit those discussions.

tmandry: Migration path for the new edition would presumably be to mark everything that is dyn safe as dyn safe, why is that a bad idea?

nikomatsakis: I guess in older editions we might leave it as unsound. Or maybe something like, in older editions, we enforce the limits but give you an opt-out (`k#not_dyn`), and in newer editions, we ask you to opt-in.

joshtriplett: +1 for your suggestion about dyn safety. I don't think we should leave a soundness issue in old editions; let's do opt-in to dyn safety in old editions and opt-out from dyn safety in new editions.

scottmcm: Do you have a link to something about that issue?

nikomatsakis: We had a design meeting and there's an issue.

scottmcm: At least we could leave a comment linking to that write-up.

nikomatsakis: I'm up to leave a comment referencing the discussion and explaining the opt-in, opt-out plan.

joshtriplett: Could we also get clear documentation (including in the reference) for precisely what restrictions apply?

pnkfelix: Is this the linked issue referenced above? https://github.com/rust-lang/rust/issues/57893#issuecomment-546972824

### "Implement pointee metadata unsizing via a TypedMetadata<T\> container" rust#97052

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

pnkfelix to un-nominate, he is still supposed to follow-up.

### "impl DispatchFromDyn for Cell and UnsafeCell" rust#97373

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

nikomatsakis requested comment and asked to renominate once comment is available.

### "Inference failure with `type_changing_struct_update`" rust#101970

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

Permit this syntax to produce a value with different generic arguments from `bar`:

let f = Foo { x, y, ..bar };

This breaks various bits of code, most notably this pattern:

fn _f() { Struct { 0: (), ..Default::default() }; }

`Default::default` is unconstrained because it is not connected to the final result type of `Struct` (for the field `0`).

If we don't want to break this pattern, we could do some sort of fallback. This would probably also break some code.

We could change it over an edition. We could also allow a specialized shorthand for `Default::default`, we could unify the types in this case:

fn _f() { Struct { 0: (), .. }; }

scottmcm: But I want `..` to be the struct field defaults, and that would allow us to support this even for cases that don't have `Default::default`.

joshtriplett: But if they don't have default they wouldn't compile?

scottmcm: But we'd not be allowed to stop compiling Default if they don't have it.

joshtriplett: Couldn't you not call it if there is no impl?

scottmcm: Yes, but if your struct had a default, we'd still have to call it.

tmandry: Is the issue that the `default` impl might not give you the same thing?

scottmcm: I expect derive-default would use the struct field defaults, and if people write an impl that doesn't use the same that's weird, but I'm worried about arbitrary side-effects that we can't get rid of which don't optimize away. Maybe the answer is "don't do that" but...

tmandry: Do we need to allow both on the same struct?

nikomatsakis: I think yes, we will want to have a "public API" and not, esp. when you consider private fields.

scottmcm: People are surprised that `..` doesn't work for private fields, they expect that `..foo` is "take took and set the fields on the mutable copy you made", but that's not what FRU does at all. There are a bunch of weird cases, like it doesn't move things if you happen to mention all the fields in the initializer.

nikomatsakis: I remember us deciding to make it respect privacy but I don't remember why.

scottmcm: Current desugar is unsound if you don't respect privacy. e.g., all of vec's fields are copy, so...

`Vec { ..other_vec }`

...if desugar takes that, you have a double free.

*and we run out the clock!*

### "Document `label_break_value` in the reference" reference#1263

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

*pnkfelix writing a comment now*

## Nominated RFCs, PRs and issues NOT discussed this meeting