---
title: Triage meeting 2023-03-21
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-03-21

## Attendance

* Team members: nikomatsakis
* Others:

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings

### Tomorrow

- "Language design principles" [lang-team#189](https://github.com/rust-lang/lang-team/issues/189)

Niko to cancel, hasn't had time to prepare.

### Later

- "Design decisions around the `#[expect]` attribute" [lang-team#191](https://github.com/rust-lang/lang-team/issues/191)
- "discuss/resolve `fn { mod { (use) super::...; } }` and its interaction with derive patterns" [lang-team#193](https://github.com/rust-lang/lang-team/issues/193)
- "Design Meeting: Field Projection" [lang-team#194](https://github.com/rust-lang/lang-team/issues/194)
- "Interface between opsem and lang team" [lang-team#196](https://github.com/rust-lang/lang-team/issues/196)
- "Temporary lifetimes" [lang-team#197](https://github.com/rust-lang/lang-team/issues/197)

## Announcements or custom items

### Meeting tomorrow, what should we do with it?

pnkfelix: Opsem discussion. I'm worried that "if miri can't detect it, it can't be UB" as a potential tenet, not convinced that's the right way to look at the problem, but also not prepared to make a doc. Should we consider an informal discussion tomorrow?

tmandry: I'd want to hear from Jacob.

pnkfelix: it's blocking this PR and I don't want it to sit in limbo.

nikomatsakis: it seems like we gotta get Ralf and Jacob in the room. Ralf was the one who suggested copy propagation. I don't know how to square undefined struct layout with miri having to detect everything.

scottmcm: The guideline of being able to detect things is a good thing, but I don't see how it can be a hard rule.

nikomatsakis: TAIT might be another option, maybe we can get all stakeholders together for that? Ping oli? Who else would we want? Josh. Let's circle back after we move a bit further.

## Action item review

* [Action items list](https://hackmd.io/gstfhtXYTHa3Jv-P_2RK7A)

## Pending lang team project proposals

None.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods" rfcs#3240

- **Link:** https://github.com/rust-lang/rfcs/pull/3240
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3240#issuecomment-1377748067):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @Amanieu
> * [ ] @BurntSushi
> * [ ] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/3240#issuecomment-1377748031):
> @rfcbot merge

Active conversation on Zulip and amidst libs forums. Maybe not an obvious check.

### "unsafe attributes" rfcs#3325

- **Link:** https://github.com/rust-lang/rfcs/pull/3325
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1396911253):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * ~~change-syntax-to-drop-parentheses~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974
> * ~~maybe-make-this-part-of-next-edition~~ resolved by https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458690311
> * syntax-not-ideal (https://github.com/rust-lang/rfcs/pull/3325#issuecomment-1458714974)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/3325#issuecomment-1396911218):
> @rfcbot merge

Concern was raised, under discussion on Zulip.

### "RFC: UTF-8 characters and escape codes in (byte) string literals" rfcs#3349

- **Link:** https://github.com/rust-lang/rfcs/pull/3349
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747916):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/3349#issuecomment-1396747889):
> I do think we should permit `br"¥¥¥"`, but I don't think we should make any of the other changes proposed in that table, for the reasons @m-ou-se stated.
>
> I'm going to go ahead and propose FCP for this. This does *not* preclude making further changes to how this information is presented.
>
> @rfcbot merge
>
> @rfcbot concern raw-byte-strings-with-unicode

### "Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc)" rust#51540

- **Link:** https://github.com/rust-lang/rust/issues/51540
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/51540#issuecomment-1448404177):
> Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [x] @Amanieu
> * [x] @BurntSushi
> * [x] @dtolnay
> * [x] @joshtriplett
> * [ ] @m-ou-se
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/51540#issuecomment-1448404145):
> After working on the OOM handler for a while, I think that the best way to move forward is to just treat OOM as a normal panic (so that it calls the normal panic handler/hooks). This is what already happens on `#![no_std]` since https://github.com/rust-lang/rust/pull/102318 was merged.
>
> I believe that we should do the same for the `std` case. Specifically:
> - The unstable `#[alloc_error_handler]` is removed. `alloc::alloc::handle_alloc_error` now always invokes the panic handler.
> - For backwards compatibility reasons, this is a [non-unwinding](https://doc.rust-lang.org/nightly/core/panic/struct.PanicInfo.html#method.can_unwind) panic. Unsafe code may not be written to correctly handling unwinding out of a memory allocation (this is in fact a frequent source of bugs in C++!). However this behavior can be overridden with `-Zoom=panic` which changes the behavior to a normal unwinding panic.
> - Since there is no separate handling for OOM any more, the unstable [OOM hook API](https://github.com/rust-lang/rust/issues/51245) in the standard library can also be removed.
>
> @rfcbot fcp close

glandium from Mozilla raised a concern about needing access to the size of the failed allocation.

Amanieu investigating giving access via custom playload (though still ordinary panic handler).

### "Tracking issue for RFC 2515, "Permit impl Trait in type aliases"" rust#63063

- **Link:** https://github.com/rust-lang/rust/issues/63063
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/63063#issuecomment-1360043090):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * ~~~~ resolved by https://github.com/rust-lang/rust/issues/63063#issuecomment-1361432898
> * docs (https://github.com/rust-lang/rust/issues/63063#issuecomment-1364525286)
> * function-defining-uses (https://github.com/rust-lang/rust/issues/63063#issuecomment-1385946789)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/63063#issuecomment-1360043060):
> @rfcbot fcp merge
>
> This has been a long-time coming. Let's Do This!
>
> [Stabilization report in this comment.](https://github.com/rust-lang/rust/issues/63063#issuecomment-1354392317)

### "Tracking Issue for "C-unwind ABI", RFC 2945" rust#74990

- **Link:** https://github.com/rust-lang/rust/issues/74990
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/74990#issuecomment-1363474839):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * docs (https://github.com/rust-lang/rust/issues/74990#issuecomment-1364528477)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/74990#issuecomment-1363474832):
> Shall we stabilize the `extern "C-unwind"` and other `-unwind` calling conventions? This change will leave `extern "C"` unchanged for now, but have the existing feature gate continue to opt into the new behavior on nightly. We'll do a separate change later to make `extern "C"` and similar not permit unwinding.
>
> @rfcbot merge

nikomatsakis resolved concern.

### "Stabilise inline_const" rust#104087

- **Link:** https://github.com/rust-lang/rust/pull/104087
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/104087#issuecomment-1350231887):
> Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
>
> Concerns:
>
> * ~~expectations-around-panics-in-inline-const~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210
> * optimization-dependent-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1449080210)
> * ~~post-monomorphization-errors~~ resolved by https://github.com/rust-lang/rust/pull/104087#issuecomment-1448730779
> * should-unused-code-cause-errors (https://github.com/rust-lang/rust/pull/104087#issuecomment-1410921524)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/104087#issuecomment-1350231871):
> Restarting the FCP from https://github.com/rust-lang/rust/pull/104087#issuecomment-1315946122
>
> @rfcbot fcp merge

we had a meeting. still not really resolved.

scottmcm: is anybody making progress on actually changing what we check here? I don't understand. There was a zulip thread in <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Preserving.20monomorphizations.20despite.20const-prop/near/338685200>, but it's not had any updates recently.

tmandry: [#108730](https://github.com/rust-lang/rust/pull/108730), run all analyses in check mode. Had some perf impact on the order of 5%.

scottmcm: wall-time says 8%, but just for check (full). debugs/opts (full), no impact. Makes sense, by the time you're emitting code, you're already doing this work.

nikomatsakis: it sounds like we want to write up a plan to report all errors and we are not ready to stabilize yet. Can we cancel this FCP since we are not ready to move forward and instead open an issue that says what we want to resolve specifically?

tmandry to author a comment on #108730 saying lang team considers a bug fix.

### "Stabilize `anonymous_lifetime_in_impl_trait`" rust#107378

- **Link:** https://github.com/rust-lang/rust/pull/107378
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/107378#issuecomment-1430287200):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/107378#issuecomment-1430287177):
> We discussed this in today's @rust-lang/lang meeting, and we think this is ready for an FCP to merge:
>
> @rfcbot merge
>
> We'd also like to make sure that future work on type-alias impl Trait (TAIT) doesn't automatically assume anonymous lifetimes will work there, and thinks carefully about how or if that should work.

We currently allow this, right?

fn foo(x: impl Fn(&u32))

Cases to consider:

* `impl Fn(&u32)`
* `impl PartialEq<&u32>`
* `impl Iterator<Item = &u32>`
* `impl Foo<'_>`

other things is

* `where T: Fn(&u32)`
* `where T: PartialEq<&u32>`

also we apparently (accidentally?) support this syntax with async functions

nikomatsakis: sometimes I wishthat `impl Foo<'_>` meant `impl for<'a> Foo<'a>`, but that wouldn't work with `Iterator<Item = ...>`

scottmcm: I see the logic that if you don't want to give it a name, you probably meant for it to work with all lifetimes

conclusion:

* Needs a better summary comment

tmandry to author a comment asking for one

### "TAIT defining scope options" rust#107645

- **Link:** https://github.com/rust-lang/rust/issues/107645
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/107645#issuecomment-1468728438):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * explicit-alternative (https://github.com/rust-lang/rust/issues/107645#issuecomment-1469979788)
> * why-not-just-the-return-type (https://github.com/rust-lang/rust/issues/107645#issuecomment-1468796621)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/107645#issuecomment-1468728409):
> @rfcbot fcp merge
>
> I propose that we accept https://github.com/rust-lang/rust/pull/107809. It implements a conservative path forward. Basically any function that constraints a TAIT but doesn't list the TAIT in its arguments/return type is a hard error, giving us room to change the behavior in the future.
>
> ### Final behavior as I understand it
>
> * A TAIT has a *defining scope* that corresponds to the enclosing module or item.
> * A *defining use* for a TAIT is any item that (a) is within the defining scope and (b) contains a function that lists the TAIT in the argument or return types, either before or after normalization (*see edge case below).
> * Within the defining scope, an item is called *constraining* if it puts constraints on the value of the TAIT. i.e., for the item to type check, the hidden type of the TAIT must have a particular value. This could occur because of a `let` (e.g., `let x: TAIT = 22_u32`), a return (e.g., `return 22_u32` in a function whose return type is `TAIT`), or in other ways.
> * Any *constraining* item within the defining scope that is not a *defining use* is a hard error. This means we can later opt to allow such a use; or to allow it with an annotation of some kind; or to make other such changes.
> * All *defining uses* must fully infer the hidden type of the TAIT and must infer the same type for the TAIT.
> * WIthin the defining scope, TAITs must always be given generic arguments (e.g., `fn foo<T>() -> TAIT<T>` and not `fn foo() -> TAIT<u32>`). This ensures inference is tractable and well-defined.
>
> ### Current bugs and limitations (forwards compatible to change)
>
> * Within the defining scope, attempts to check whether `TAIT` implements an auto-trait will yield a cycle error unless the auto-trait is listed in the TAIT's bounds. This is suboptimal, but the ideal fix is unclear.
> * A function that has an argument which is an associated type referencing a TAIT (e.g. `<TAIT as SomeTrait>::SomeItem`) ought to be considered a *defining use*. However, in the compiler today, if that associated type can be normalized, and the normalized form does not reference the TAIT, the function is not. This can only cause more errors.
>
> @rustbot labels -I-lang-nominated

type Foo = impl Trait;

fn some_function() -> Foo { }

fn some_function(f: Foo) { }

* Few concerns were raised on previous conservaitve role
* Tyler: they would prefer to have only `-> Foo` as a legal defining use
* Dirbaio: explicit attributes, e.g., `#[defines(Foo)] fn some_function`

Niko proposed ATPIT as a concerete, but even there, there are some questions, e.g. is this ok

impl SomeTrait for Bar {
    type Foo = impl Debug;
    
    fn foo(&self) {
        let f: Self::Foo = 0u32;
    }
}

pnkfelix: oh dear god the acronyms, don't do this to us

tmandry: if we did do `#[defines]`, would you want it also at the impl level?

nikomatsakis: depends if you think of an impl as a "mini-module", in which case I think it seems consistent, or as a small unit. I tend to think of it as the latter. In a module, I feel like there are often various bits of code put together, and so having `#[defines]` link to the associated type is nice-ish.

mod some_module {
    type Foo = impl Debug;
    
    #[defines(Foo)]
    fn bar() -> Foo {
        
    }
    
    fn baz() { 
    }
}

tmandry: I think the inconsistency will be hard to explain, but I also think it's usually not needed in impls

pnkfelix: some impls get large, I could imagine it (the attribute) being useful to search for

scottmcm: can't you search for the name of the associated type... wait, what happens with this case?

impl Add for T {
    type Output = impl Debug;
    fn add(self, rhs: Self) -> u32 { … } // Defining use?
}

Is it a "mention" because it's used in the trait definition for that position? Or only if it's there lexically in the impl?

nikomatskais: currently, the check that impl matches trait is done without knowledge of hidden type, so that example does not build, you have to write `Self::Output`:

[playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=1824588c6d78ca39677b059e52ca6496)

[this does build](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=0369686dc23238769f3ccd06cb7a403b)

tmandry: would it help to list out the use cases ...?

* returning an iterator
* returning futures, closures

impl IntoIterator {
    type Item;
    type IntoIter = impl Iterator<Item = Self::Item>;
}

impl Service for Something {
    type Future = impl Future<Output = ...>;
    
    fn service(&mut self) -> Self::Future {
        async move {
            ...
        }
    }
}

Question we need to answer:

> * Are there any use cases that do not involve the opaque type appearing in the return type or in the type of a const/static?
> * Arguments in favor of defines instead of just return position (answer is primarily if you want to scale to other positions?).
> * What are all the patterns?

### "Make late_bound_lifetime_arguments a hard error." rust#108782

- **Link:** https://github.com/rust-lang/rust/pull/108782
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108782#issuecomment-1468627626):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * types-team-input (https://github.com/rust-lang/rust/pull/108782#issuecomment-1477170467)
>
> 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!
>
> cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
> 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/108782#issuecomment-1468627594):
> @rfcbot fcp merge
>
> Discussed in a (minimally attended) lang-team triage meeting and we are in favor of moving forward with this.
>

blocked on a concern.

## Active FCPs
### "RFC: result_ffi_guarantees" rfcs#3391

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

### "Clarify stability guarantee for lifetimes in enum discriminants" rust#104299

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

### "Add a builtin `FnPtr` trait that is implemented for all function pointers" rust#108080

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

### "Initial support for return type notation (RTN)" rust#109010

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "RFC: Postfix match" rfcs#3295

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

remove nomination, scottmcm is to kick off a FCP

tmandry asks the dreaded question: "why now"

scottmcm: biggest reason honestly is "it's had all the conversation it's going to have, no new information, let's reach a decision". I'd use it occasionally, but I don't think anyone is wrong to say "you don't really need it".

tmandry: what about temporary lifetimes?

nikomatsakis: really interesting point. I wonder if people's expectations are different.

scottmcm: another point that was raised is auto-ref, RFC currently says no. But it's similar.

nikomatsakis: another question, what is the "killer use case", I think maybe `try/match`

scottmcm: for me, map-or-else, because that always make me sad, two closures in the wrong order and not understood by borrowck

nikomatsakis hates map-or-else with the passion of a thousand fiery suns

tmandry: if RFC were extended with answers to the below, I would be comfortable making a decision:

* killer use cases and patterns (likely already present in motivation)
* auto-ref interaction
* temporary lifetimes
* how it might interact with postfix macros

nikomatskis charges scottmcm to follow-up.

### " Make typeck aware of uninhabited types" rust#108993

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

> This PR modifies the unreachable code lint to operate from within typeck, based on inhabitedness of types discovered as the analysis goes. As a consequence, the lint fires in many extra places. Constructors are carved out on purpose, to avoid an "unreachable call" diagnostic on them, which is not very useful as they are inert.

nikomatsakis: we probably won't conclude this, but I definitely want a better understanding of what this PR actually does. hard to tell what unexpected interactions may result.

pnkfelix: skimming the output, I like the idea that it's showing we already had code that was unreachable, but now we give a better result, e.g., it's telling you "it had this type, which is uninhabited".

tmandry: do people know what uninhabited means?

pnkfelix: "which cannot be constructed"

scottmcm: sounds like visibility

pnkfelix: "which has no value"

scottmcm: as long as "uninhabited rust" hits the right thing in google? or verbose error?

pnkfelix: how about we retag it T-types? can we come to general approval?

nikomatsakis: I feel like wearing either hat I don't know what I'm approving. I know it's taking inhabitnedness into account but I don't know exactly *how*.

tmandry: No blocking concerns that come to mind, but I'd like someone to explain if there's anything we should be looking at carefully.

scottmcm: std-err diffs seem reasonable, but there are only two of them.

### "The `#[diagnostic]` attribute namespace" rfcs#3368

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

looks like last time we identified design meeting as a next step?

pnkfelix: do we want to identify a champion?

tmandry: seems like we are not on same page as a team, Josh gave advise towards versioning, I didn't like it

tmandry: I can file a meeting for a design meeting proposal but keep it light on the requirements

nikomatsakis: we can read rfc or a subset of it

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

### "unsafe attributes" rfcs#3325

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

### "RFC: Start working on a Rust specification" rfcs#3355

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