---
title: Triage meeting 2023-01-17
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-01-17

## Attendance

* Team members: nikomatsakis, tmandry, scott, Josh, pnkfelix
* Others: simulacrum

## Meeting roles

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

## Scheduled meetings
* https://github.com/rust-lang/lang-team/issues/190
* welcome outside participants to join and observe

## Announcements or custom items

### Niko at POPL this week

Will report if anything comes out that seems relevant!

### Item from libs-api meeting

- Generalized handling for `try_` methods, closures with non-local control flow?
- keyword generics is taking aim at this problem, and is exploring being generic over try, async, const (also: panic vs abort vs infallible)
- scottmcm: fold can't do try-fold because they have different self types. This makes a huge difference sometimes.
- joshtriplett: impossible to write one method that does both?
- scottmcm: not impossible, but the shortcircuiting ones that wish to be able to resume, is very different from the consuming ones that want to ...
- joshtriplett: i.e., how await wants to go back in?
- scottmcm: `try_fold` is there because it will stop, so it has to maintain state in the thing you are iterating, but the folds that people write intentionally do not maintain state, so you can't update a fold to a try-fold with compiler magic
- joshtriplett: going back to that notion, in theory you could have a function that took `&mut`, but that would not work for people who wanted a consuming closure, but it'd still work for everyone else?
- scottmcm: given that one can implement fold in terms of try-fold today, absolutely, if you have the mutable version that's resumable, you can choose to not resume it...
- joshtriplett: fold is useful in terms of taking something that consumes, but ignoring that problem we might be able to do other methods that don't have it
- scottmcm: things like all/any, those are already shortcircuiting, so being *more* shortcircuiting isn't a problem, but a bunch of iterators, people have gone through and implemented `fold` differently from `try_fold`, since it makes a material perf difference to not maintain state, so we'd also need the ability to specialize in keyword generics
- joshtriplett: makes me wonder if keyword generics could also include references, e.g., self, `&mut`, etc
- tmandry: I've brought up the mutability effect as well but I don't know if they're working on it
- scottmcm: can we find a clever way to do a wrapper? See https://github.com/rust-lang/rfcs/pull/3233#discussion_r815183078
- nikomatsakis: it's true that keyword generics is looking at this, it's also true that `?`-being-able-to-break-out-of surrounding frames could be nice, lots to figure out there
- joshtriplett: if function has to be aware that it might be 'jumped over' by closure it calls, then keyword generics seems like as good a way as any
- nikomatsakis: +1

### governance RFC

Feedback welcome.

## 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
### "Create an Operational Semantics Team" rfcs#3346

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

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

This FCP request kicked off a lot of fresh conversation.

nikomatsakis: I'll point out the obvious that if we want this available for Rust 2024, we need to do it soon.

pnkfelix: I posted my main concern.

scottmcm: Spaceship operator! An operator for ord-cmp. Useful when deriving, that or sort-by.

joshtriplett: Main advantage is that you don't need to have a close paren..?

scottmcm: Behaves like the other comparison operators with respect to references. If you write `a.ord(b)`, usually looks like `a.ord(&b)`.

joshtriplett: So should we have autoref for the RHS? (troll face)

scottmcm: Not sure I'm saying that.

nikomatsakis: I feel negative!

scottmcm: I think I got my straw poll.

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

Currently proposed for merge, concern about docs that's not been addressed.

docs pr: https://github.com/rust-lang/reference/pull/1317

nikomatsakis: oli is working on docs, but he mentioned that people were raising concerns about being able to limit the scope of inference for better IDE integration.

(See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/TAITs.20and.20lazy.20parsing/near/321580861))

type Foo = impl Debug;

fn bar() { // less obvious
    let f: Foo = 22_i32;
}

fn bar() -> Foo { // obvious for IDE
    22
}

scottmcm: Sorta related: \[Edition vNext\] Consider deprecating weird nesting of items [#65516](https://github.com/rust-lang/rust/issues/65516#)

joshtriplett: I buy this distinction even outside of IDEs, to be able to easily find where it's being influenced.

nikomatsakis: my reaction was also that I didn't have total confidence in this part of the design, and wouldn't mind scaling it back.

joshtriplett: somebody up to writing a comment?

tmandry: I'm also concerned about tying together the inference with opacity.

joshtriplett: you could imagine having opacity without extra inference.

scottmcm: workaround for now is something like

type Foo = impl Debug;
fn _foo() -> Foo { identity::<MyType>(panic!()) }

nikomatsakis: I assumed that at some point we would permit explicit opaque types to be declared and (optionally) specify the hidden type, but that would still be opaque:

/*opaque*/ type Foo: Debug = i32;

...wouldn't address the second part. You could also imagine wanting a type that is *not* opaque but *is* inferred, e.g.:

type Foo = _;

joshtriplett: main case is big ugly type, but if it's a big ugly type, maybe you don't want to be tied to its specifics?

nikomatsakis: adding inherent methods

type Foo = _;
fn foo() -> Foo {
    async move { }
}

impl Foo {
    fn custom_method(&mut self) { 
        self.x // need some way to access upvars
    }
}

tmandry: https://david.kolo.ski/blog/a-new-impl-trait-2/ talks about this

nikomatsakis: I think we should move on, don't see a reason to block this stabilization now.

joshtriplett: If we want opaque type and -- more broadly -- inferred type to be completely orthogonal. You might want opaque without inference, which is easily added, and I don't think that we're going to want more widely inferred without opacity.

pnkfelix: Not convinced. I think there's cases where, in terms of semver, you are saying, I want Rustdoc to commit to the type, but I don't want to write it down.

joshtriplett: can't you copy and paste the type in that case?

nikomatsakis: in terms of this stabilization, I don't see that we're going to stabilize `type Foo = impl Trait` to have *exposed* semantics, we've got `-> impl Trait` and it does its things. I do think there's room for confusion between `type Foo = impl Trait` that desugars to some future `opaque type Foo: Trait`, but we've had that discussion a lot, and if we want just one syntax, it's definitely the former. So I think we should move forward. =)

### "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
> * [ ] @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

joshtriplett: Is someone working on the docs concern?

tmandry: there are PRs?

nikomatsakis: are they ready to go?

tmandry: I don't think all those comments have been addressed yet.

nikomatsakis: we've been asked to shoot for "doc PRs are approved and ready to merge" by docs team.

### "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 (https://github.com/rust-lang/rust/pull/104087#issuecomment-1379582240)
>
> 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

tmandry: I have some comments on this. First is bikeshed-y, but gets at a larger question. When I think of `const`, the first thing that comes to mind is not "inline const this will be an easier way to raise errors at compilation time". Oli replied, "that's the only thing I think of". I wonder if this matches the expectation of users. I find it surprising. My expectation is that this will guarantee execution at compilation time.

https://github.com/rust-lang/rust/pull/104087#issuecomment-1382598919

gary guo: I'd like to point out that this is consistent with other languages. Our semantics matches theirs. I don't think other languages had this issue here.

tmandry: C++ doesn't support throwing in constexpr, right?

garyguo: In my latest comment, I showed how in compile time, you get an error, although it's not the same as our const panic (which imo is nicer than C++ error that this gives) -- "throwing not allowed in const expression".

tmandry: zig has this difference between "const" -- for items -- and "comptime" -- this is happening at compilation time. We don't have a way to investigate these more bikeshed-y questions, and I don't want to bog down the current process.

garyguo: main point that compiler team + ralf + myself are arguing is that what we are doing is matching what associated constants are doing. Associated constants are already defined by the const keyword, so not too much of a difference.

tmandry: Prior art discussion makes sense for me, but the larger part I'm trying to raise, lang team doesn't have a good way to evaluate usability questions.

nikomatsakis: Just want to throw in the idea of usability office hours -- been talking to Felienne about setting up that sort of thing. To help give answers.

joshtriplett: We should do that, but also, the answer is likely to be "ask a bunch of users", and we don't have a good process for doing that right now.

joshtriplett: Reasonable open question: how much does calling this `const` meet people's expectations from other uses of `const`, vs confusing people?

scottmcm: How can you care whether something was computed at compilation time, other than compilation errors? Rvalue static promotion?

pnkfelix: Other than actual runtime, you mean?

scottmcm: Right but it's not observable and anyway it will likely get const-folded anyway.

garyguo: not necessarily, if the expression is complex. For example, things might be partitionated across codegen-units, and const evaluation would be needed.

nikomatsakis: I feel a bit confused, what is the crux of what we're talking about?

garyguo: three different views of what we're talking about. One of them is that every constant should be well-formed (e.g., by @afetisov). Another view by Tyler which is that maybe all errors should be delayed to runtime. Middle-ground view that everything will be evaluated at compilation time, error is at compiltion time, but the error may be post-monomorphic. Not guaranteed to be WF, but may fail at monomorphization.

tmandry: To be clear, I'm not advocating that we delayed panics until runtime, but it seems like an expectation someone might have. That wrapping an expression in `const` is unobservable. The fact that this can cause post-monomorphization errors. Hard to know what expectations users will come in with.

scottmcm: Users probably haven't developed a clear intution since what const did changed relatively recently. Used to be that panicking in item const wasn't a compilation error, it would be really easy for someone to have the model that was true 7 releases of Rust ago, but isn't true today. Which might make it extra hard.

nikomatsakis: Why...would they think that wrapping an expression in `const` is unobservable?

tmandry: They think of const as a way to force const promotion that gives you speedup.

nikomatsakis: Other question is what is the harm if they get confused, seems relatively low, right?

tmandry: Yes, using this as a way to get at a larger point, of matching user expectations.

tmandry: Wanted to raise a separate point about post-monomorphization errors. Not sure if this should be blocking, but I'd like to get a clearer picture of how we think of post-monomorphization errors in the Rust language. What's the rationale for having a trait system that avoids them almost always, but other features that allow them?

scottmcm: It would be relatedly interesting to ask "when would libs API be willing to have a post mono error in a stdlib function", for example. Is it never?

scottmcm: Don't disagree with any of what you're saying, but maybe the answer is we didn't raise the monomorphization questions here. As soon as we had associated constants, we had that problem.

GaryGuo: just so you know, already have uses of const to do asserts in the stdlib.

tmandry: triggerable by a public API, or more of an internal consistency check?

GaryGuo: the latter. but maybe libs-api might want to make some errors post-monomorphization, instead of delaying, e.g., `uninitialized::<T>()`...?

scottmcm: that'd be a breaking change, just because it's monomorphized, doesn't mean it actually gets called. We have a lot of code in the library that's like "if T is a ZST...", and that would blow up horribly.

garyguo: maybe a post-mono warning?

nikomatsakis: it could be silenced with an allow.

tmandry: there's where my mind went, I think, the "oh this is an expression, and they are flow-sensitive"

nikomatsakis: scott's example triggered something for me, the idea would be a guarded const that you know will work, but which isn't reachable in other cases?

garyguo: what about new cases -- e.g., in Rust For Linux project, we want to use inline const to do post-mono errors where trait system is unable to express (e.g.), size cannot be zero. We prefer to make it post-mono instead of runtime error.

scottmcm: we probably don't want more post-mono errors until we have a language level way to control what gets monomorphized. Here's an example:

https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.as_chunks

still nightly because we can't figure out how to make it work with empty arrays. Unresolved conversation of "do we need to wait for where N > 0 as a const bound? is panic ok? would a post mono error be acceptable?"

scottmcm: could make `if const` impact monomorphization...? `if const { ... }` maybe we want to avoid errors until we guarantee what we monomorphize?

garyguo: still have assoc const which has this behavior, right?

*ran out of time*

nikomatsakis: not sure I would block, but I do see the concerns

_tmandry note: Ralf had a suggestion for rationalizing post-mono errors here:_ https://github.com/rust-lang/rust/pull/104087#issuecomment-1382712576

## Active FCPs

None.

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Clearly specify the `instruction_set` inlining restrictions" reference#1307

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

Waiting on author. Removed nomination.

### "Allow only implementing `Read::read_buf`" rust#106643

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

Question of: could we just document and stabilize this feature? `#[rustc_must_implement_one_of(...)]`? (as `#[must_implement_one_of]`)

scottmcm: Originally I thought I had no objection, but then conversation

nikomatsakis: I would want an RFC, I suspect that talking about it would yield useful ideas too.

scottmcm: I think our lang process requires an RFC, right?

joshtriplett: Could be a short RFC

scottmcm: Might be longer, given some of what Oli was bringing up. If we ever wanted "you get a different default depending on which things you overrode", for example. Maybe that's a non-issue that we don't want?

(re oli, see [zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rustc_must_implement_one_of/near/320835444))

joshtriplett: Wouldn't go as far as we don't want that, but it sounds like a corner case we could extend to later.

scottmcm: I bring it up because the place I would put the attributes, and how I'd phrase it, would probably be different. e.g., does this live on the trait def'n, on methods in the trait def'n? *or some third option Niko didn't catch* All of them are possible, but I'd want the RFC to convince me which.

## Nominated RFCs, PRs and issues NOT discussed this meeting
### "RFC: Start working on a Rust specification" rfcs#3355

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

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

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

### "Implement a lint for implicit autoref of raw pointer dereference " rust#103735

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

### "make &mut !Unpin not dereferenceable, and Box<!Unpin> not noalias" rust#106180

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

### "Introduce terminating scope for tail expressions of breakable scopes" rust#106493

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

### "inline_const does not evaluate in unused function" rust#106617

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