---
title: Triage meeting 2023-06-13
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-06-13

## Attendance

* Team members: Tyler, Scott, Josh
* Others: Urgau, Lokathor, TC, dtolnay

## Meeting roles

* Action item scribe: Tyler
* Note-taker: Tyler

## Scheduled meetings
- "The #[diagnostic] attribute namespace" [lang-team#204](https://github.com/rust-lang/lang-team/issues/204)

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

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

## `S-waiting-on-team`
### "Tracking issue for dyn upcasting coercion" rust#65991

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

Need data. Look again next week, and wait to include Niko in the discussion.

### "feat: split `unsafe_code` lint into lint group" rust#108975

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

..discussion around implementing `unsafe fn` in traits...

TC: An unsafe function without an unsafe block (even if we required that) can still introduce unsafe behavior because unsafe happens at the crate level and the function could create obligtions.

scottmcm: `set_len` could do something bad

joshtriplett: you can introduce an obligation but cause undefined behavior if someone uses that

Lokathor: motivation seems to be that people want to implement unsafe method in trait that doesn't use unsafe. should the resolution be that we already have an RFC to solve this problem?

joshtriplett: Does anyone feel that if we had that RFC implemented that we'd still want to split these out?

TC: I see a conceptual distinction between creating and discharging an unsafe obligation. We've discussed this in other meetings, e.g. for unsafe attributes. But it's probably bigger than this one issue.

scottmcm: Feels weird to me that you'd be defining obligations in an unsafe trait that others would actually be depending on.

joshtriplett: I agree with TC that there is a distinction. Point I wanted to raise was, do we think people will want to forbid one and allow the other in real life?

Lokathor, tmandry, Josh: No

scottmcm: The RFC would solve the problem more nicely.

joshtriplett: I propose someone writes a comment linking to the RFC for safe unsafe trait method impls and asking for some detailed use cases where even given that RFC, people would want this to be done differently. Looking for non-hypotheticals.

scottmcm: How do we feel about stabilizing that RFC?

tmandry: I would want to wait on the result of the `#[refine]` user study before stabilizing.

scottmcm: Do we have the option of allowing you to not write `unsafe` but still requiring the caller to write it?

joshtriplett: We probably want to have a better idea of the end state first.

Lokathor: It would solve the original use case for this change.

joshtriplett: I don't want to settle the solution to that RFC now, if we think it's the better solution we should propose that

TC: I can write the comment, where's the RFC

scottmcm: <https://rust-lang.github.io/rfcs/2316-safe-unsafe-trait-methods.html> is accepted to allow implementing `unsafe fn`s on traits without using `unsafe fn` in the implementation of the trait.

tmandry: And the `#[refine]` RFC 3245 modifies it to require `#[refine]` if you don't use `unsafe` in your impl.

### "make `noop_method_call` warn by default" rust#111916

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

joshtriplett: We asked for a crater run and someone did that; need a summary of the crater results. Will add a comment.

tmandry: Specifically for clone, deref?

scottmcm: Yes, uplifted from clippy. 99% of the time you called clone on a reference and it cloned the reference.

### "resolve: Remove artificial import ambiguity errors" rust#112086

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

in FCP; untagged and unnominated.

## Proposed FCPs

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

### "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
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * raw-byte-strings-with-unicode (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1396747889)
> * waiting-on-update-re-using-char-and-string-tables (https://github.com/rust-lang/rfcs/pull/3349#issuecomment-1503875165)
>
> 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

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

- **Link:** https://github.com/rust-lang/rfcs/pull/3355
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1513641410):
> Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * naming (https://github.com/rust-lang/rfcs/pull/3355#issuecomment-1587572543)
>
> 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/3355#issuecomment-1513641387):
> @rfcbot fcp merge
>
> We talked about this in the lang team triage meeting and agreed that this is ultimately a council-level decision. That said, it seems like a good idea to get formal lang team buy-in ahead of the council making a decision on this.
>
> Since we can do that now while the council is still forming, I'm opening an FCP for it. **Note that this will still need a _separate_ FCP to actually be merged once the governance council is formed.**

### "Tracking issue for RFC 1868: A portability lint" rust#41619

- **Link:** https://github.com/rust-lang/rust/issues/41619
- [**Tracking Comment**](https://github.com/rust-lang/rust/issues/41619#issuecomment-1548112936):
> Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [x] @joshtriplett
> * [x] @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/issues/41619#issuecomment-1548112912):
> It seems like the current consensus among @rust-lang/lang is that this isn't the approach we want to go after all, and we'd like something *type-based* rather than *lint-based*. For instance, something based on the various "capabilities" proposals for global impls of a `Trait`, together with `where` clauses.
>
> @rfcbot close

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

### "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
>
> Concerns:
>
> * elaborate-cases-and-future-directions (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
> * why-not-higher-rank (https://github.com/rust-lang/rust/pull/107378#issuecomment-1480280524)
>
> 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.

### "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-1571789843):
> Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [x] @scottmcm
> * [x] @tmandry
>
> Concerns:
>
> * encapsulation-is-too-powerful (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
> * nested-modules-can-always-define-but-nested-functions-cannot (https://github.com/rust-lang/rust/issues/107645#issuecomment-1585420743)
>
> 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-1571789814):
> @rfcbot fcp merge
>
> We held a design meeting yesterday where we reviewed [this document](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2023-05-31-TAIT-stabilization.md) prepared by @oli-obk and TC (not sure github name) but also with feedback/input from @matklad and others, particularly around IDE requirements.
>
> The document proposed the following resolution to this issue:
>
> - The hidden type may be constrained only within the scope of the item (e.g. module) in which it was introduced, and within any sub-scopes thereof, except that:
> - Functions and methods must have the hidden type that they intend to constrain within their signature -- within the type of their return value, within the type of one or more of their arguments, or within a type in a bound.
> - Nested functions may not constrain a hidden type from an outer scope unless the outer function also includes the hidden type in its signature.
> - A hidden type is considered to appear within the signature if it appears directly or is reachable via traversing field or other element types or via normalization.
> - The hidden type may be constrained by functions, methods, constants, and statics.
>
> The doc goes into more detail about the justifications and alternatives.
>
> Given all this, I propose to merge and accept this proposal.

### "Add `internal_features` lint" rust#108955

- **Link:** https://github.com/rust-lang/rust/pull/108955
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/108955#issuecomment-1564739018):
> Team member @scottmcm 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
>
> 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/108955#issuecomment-1564739001):
> I was pondering whether this is more lang or more compiler, but with a compiler MCP already complete,
>
> @rfcbot fcp merge
>
> I support giving stronger discouragement from using `S-tracking-perma-unstable` things.
>

### "Uplift `clippy::option_env_unwrap` lint" rust#111738

- **Link:** https://github.com/rust-lang/rust/pull/111738
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/111738#issuecomment-1559994605):
> Team member @nikomatsakis has proposed to close this. The next step is review by the rest of the tagged team members:
>
> * [ ] @joshtriplett
> * [x] @nikomatsakis
> * [ ] @pnkfelix
> * [x] @scottmcm
> * [ ] @tmandry
>
> Concerns:
>
> * move-errors-left (https://github.com/rust-lang/rust/pull/111738#issuecomment-1564194388)
>
> 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/111738#issuecomment-1559994585):
> @rfcbot fcp close
>
> We discussed this in the lang-team meeting and felt it did not meet the rustc bar of preventing bugs or helping to shape ecosystem wide consistency (like naming conventions).
>
> We would be interested in some kind of "custom lint" mechanism. Ideally this would be a pattern-matching scheme that would ecosystem crates provide this sort of lint. A more limited thing might be something like #[must_use] (e.g., #[prefer_on_unwrap("env!")], but some members of the team were skeptical of such a narrow purpose attribute. Regardless that would be a separate proposal that would ultimately require an RFC.
>
> The motivation here is that we think "usage lints" like this add value, but to do so, you need an awful lot of them, and we think the best way to get that is to let people add them themselves. Otherwise, clippy is a better home.

## Active FCPs
### "resolve: Remove artificial import ambiguity errors" rust#112086

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Does T-lang have opinion on floating-point guarantees?" lang-team#210

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

Lokathor: To what extent does Rust have a clear floating point semantic vs just doing what the hardware does etc

pnkfelix: For example, do we guarantee IEEE semantics.

tmandry: My feeling is that it's too constraining to guarantee a particular semantics, but I'm also very wary of something like `-ffast-math` where a compiler option changes the behavior of your code.

Lokathor: T-opsem wanted T-lang to handle this as much as possible

Lokathor: for example could there be a `#[cfg]` thing that says we support IEEE

TC: This feels connected to language design principles. Not undefined behavior exactly but a related concept, implementation-defined behavior.

scottmcm: Our docs say we respect IEEE: https://doc.rust-lang.org/std/primitive.f32.html

joshtriplett: What about non-tier-1 targets, are those allowed to be noncompliant? We could make i586 compliant, iff we didn't care about performance.

scottmcm: I would propose we should make primitive types do the obvious portable behavior, but add operations that would do the "weird" things. Your target needs to provide that and add other types for the "fast" path for your hardware.

joshtriplett: Need to answer: what's the default, who gets to opt into non-default, is that allowed to affect other code?

TC: Scott as I understand him is proposing that everything has deterministic behavior on all platforms?

scottmcm: True for default operations. I think there's space to have "functionally nondeterministic" behavior for floating point. This operation has to work within these bounds, but exact behavior is not specified.

joshtriplett: I think it's important to have deterministic behavior by default. People want to write test cases.

joshtriplett: On some modern platforms people want to turn on FMA by default. Then we need to answer whether we are able to optimze to FMA without a dedicated method, or if people *have* to call a dedicated method to opt into that.

joshtriplett: One of the problems with `-ffast-math` is that it conflated too many things: less accurate, more accurate.

scottmcm: Not a fan of "the binary picks something for all libraries". I would like my compensated summation to work, regardless of whether the binary thinks allowing some collapsing in it is "more accurate".

tmandry: I think we need some way of controlling how floating point code behaves at the binary level. Maybe you have to link with a binary blob written in C...

TC: There's a research question here: how far can we push special-purpose methods like we do on integers?

scottmcm: One thing I'm inspired by here is things like [`__mm512_mask_rsqrt14_pd`](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=sqrt&ig_expand=5729), which has

> The maximum relative error for this approximation is less than 2^-14.

and thus that would be allowed to do anything within those bounds, and sound `unsafe` code would be required to be valid no matter what result in that space actually came out. (Like how, practically, things like `tan` are only ±1ULP, and thus can return one of two different possible values.)

joshtriplett: Does anyone in this meeting feel inclined to come up with a design?

pnkfelix: Could we talk about this some in the language design principles meeting? Could be a good exercise.

Josh to mention to Niko as a case study for language design principles

tmandry: I can try to anonymize a use case I heard recently.

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

### "Explicit Tail Calls" rfcs#3407

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

### "dyn Trait comparison should not include the vtable pointer" rust#106447

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

### "Add `internal_features` lint" rust#108955

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

### "feat: split `unsafe_code` lint into lint group" rust#108975

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

### "Make pointer_structural_match normal and warn" rust#110166

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

### "Create `unnecessary_send_constraint` lint for `&(dyn ... + Send)`" rust#110961

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

### "optimizing Use expressions inside if condition (take 2)" rust#111725

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

### "Uplift `clippy::option_env_unwrap` lint" rust#111738

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

### "let-else does not support `else if`" rust#111910

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

### "resolve: Remove artificial import ambiguity errors" rust#112086

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

### "Should associated type bounds on supertraits be implied?" rust#112573

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

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

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