---
title: Triage meeting 2023-05-23
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2023-05-23

## Attendance

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

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings

https://github.com/orgs/rust-lang/projects/31/views/10

* May 17 -- RPITIT stabilization schedule
* outcome: good to move forward, edits to RFC are done
* likely to stabilize intersection of refine/not-refine
* May 24 -- RTN (nikomatsakis/tmandry authoring doc)
* May 31 -- TAIT defining scope options (oli authoring doc)

## Announcements or custom items

### Unsafe extern blocks

Pre-RFC: https://hackmd.io/@Lokathor/Skl1OucSn

Motivation: trusted external declarations.

External declarations by themselves can cause UB.

So make them unsafe to declare (in next Edition), which also allows for safe external functions.

### Scoped impls and trait privacy?

nikomatsakis: I'm toying with the idea of authoring an RFC for making crate-private impls, and then I'm finding I would like to correct some of the other visibility things like methods in traits should be `pub` so that you can copy/paste...

pub trait Foo {
    pub fn foo(&self);
}

pub(crate) impl Foo for Bar { }

scottmcm: traits + specialization seem complicated, but I'd very much like to have it.

nikomatsakis: yeah, I imagined specialization would see the impl, but this is very pre-pre-RFC, that's the kind of complication I'm looking for.

scottmcm: what does a "pub in private" impl look like?

TC: can you have a private impl of an external trait for an external type?

scottmcm: not if specialization can see it!

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

still waiting on wafflelapkin for data.

### "Allow partially moved values in match" rust#103208

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

This might all opsem? We should certainly write up what we think our thinking is.

nikomatsakis: felix?

pnkfelix: yeah. I can do something here.

ACTION ITEM: pnkfelix to review design meeting notes and contact opsem team.

scottmcm: lowering from thir to MIR, is that opsem?

nikomatsakis: often not but matches/patterns is where things get tricky and I think it is.

### "Uplift `clippy::invalid_utf8_in_unchecked` lint" rust#111543

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

no longer waiting on us.

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

### "Return position `impl Trait` in traits" rfcs#3425

- **Link:** https://github.com/rust-lang/rfcs/pull/3425
- [**Tracking Comment**](https://github.com/rust-lang/rfcs/pull/3425#issuecomment-1531916403):
> 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
> * [ ] @scottmcm
> * [x] @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/3425#issuecomment-1531916376):
> @rfcbot fcp merge
>
> This feature has been a long time coming and feels like a no brainer to me. I'm going to start the merge proceedings.

Basically what we read the doc about on Wednesday.

RFC includes `#[refine]` but that has already been RFC'd.

Wednesday conclusion was that we would start by stabilizing the intersection without `#[refine]`.

nikomatsakis: we've been discussing whether or not to stabilize `async fn` without RTN (i.e., at same time as RPITIT).

tmandry: Section in RFC is https://github.com/tmandry/rfcs/blob/rpitit/text/0000-return-position-impl-trait-in-traits.md#scoping-rules-for-impl-trait

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

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

design meeting is scheduled

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

lokathor: posted a comment, ralf has an example of a "late error" that happens in both debug and release, his example is slightly different.

scottmcm: it is the case that the thing we are de facto blocking on here is something that already exists and can be triggered. The concern is that it becomes easier. Sort of an awkward "this is an existing problem that we're blocking on" but we've acknowledged that in the meetings -- don't technically have to block on this, but still trying to anyway.

nikomatsakis: I'm concerned it's in that state where people don't know what to do to unblock it.

scottmcm: .... compiler details etc etc ... some way to look at consts in callees even if they're optimized out ...

nikomatsakis: what I'd like is a clear stmt of what we expect. Last time we said something about cargo check, for example.

scottmcm: inline constants should fail regardless of debug/release but not necessarily cargo check.

garyguo: only non-generic const items are guaranteed.

... missed comments ...

scottmcm: vibe I got from the meeting was that this was going to make it so much easier than it used to be and so it's going to be much more common. i.e., before, it's kind of a hack that exposes this.

gary/TC: examples exist that do rely on whether things are monomorphized for static assertions.

tmandry: we want to eliminate the opt-dependent errors. We can kick the can down the road with respect to cargo check.

nikomatsakis: my sense is that people don't have a clear picture of what we think is needed. Not a one-line comment but an open issue that describes what should work and not.

TC: are we sure we want to block on fixing this bug?

tmandry:I think we should block on it.

garyguo: it could be backwards incompat. We need to run crater.

tmandry: that's fair, I could see us making a different decision based on data.

nikomatsakis: is anybody working on pushing this forward?

garyguo: on my todo list, but that list is long

nikomatsakis: I want oli to focus on taits!

lokathor: this is blocking consts in inline assembly as well

gary: same issue.

nikomatsakis: It'd be great to move it forward. I am concerned about defacto lock-in.

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

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

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

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

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

### "Stabilize inline asm for LoongArch64" rust#111235

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

### "Uplift `clippy::undropped_manually_drops` lint" rust#111530

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

### "Uplift `clippy::invalid_utf8_in_unchecked` lint" rust#111543

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

### "Uplift `clippy::cast_ref_to_mut` lint" rust#111567

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

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

### "Uplift `clippy::undropped_manually_drops` lint" rust#111530

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

already in fcp, should be un-nominated

### "Uplift `clippy::invalid_utf8_in_unchecked` lint" rust#111543

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

already in fcp, should be un-nominated

### "Uplift `clippy::cast_ref_to_mut` lint" rust#111567

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

already in fcp, should be un-nominated

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

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

Seems like there is consensus that including type-id in the vtables is the only way to move forward. Unclear why would be a problem though.

garyguo: increases vtable size by 16 bytes, since type-id is going to increase to 128 bits. #109953

be wary of C++.

nikomatsakis: only other option I see is deprecating raw pointer comparison, but we still need to define the behavior on older editions.

nikomatsakis: the status quo doesn't super bother me, it's leaks more impl details than I would like, but I like it better than ignoring the vtable altogether. I would say we can rule that one out.

nikomatsakis: I can't justify why we should spend time every meeting talking about this.

tmandry: if we have two dyn debugs, one for the tuple, and one for the first element, they don't seem like they should be equal.

scottmcm: I'd be in favor of some kind of lint.

tmandry: is it possible to deprecate `PartialEq` on unsized?

scottmcm: not really

nikomatsakis: not at the moment...moved to close

garyguo: should we remove the partialeq / eq impl on dyn metadata?

nikomatsakis: probably, that's a good point. if we can get away with it.

scottmcm: we can't, we'd need *something*, we need dyn pointer to be implemented using something? doesn't need the trait impl?

garyguo: in a future edition we could potentially add a bound like "can only compare where metadata is partialeq"

scottmcm: I think there is some problems where "pointer to T" is always partialeq etc but... we might be able to get away with it.

### "Explicit Tail Calls" rfcs#3407

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

[comment from yesterday](https://github.com/rust-lang/rfcs/pull/3407#issuecomment-1556730754) was to bring attention:

* implementation creates and some lessons were learned
* things we might not want to stabilize initially
* thoughts from team on:
* what syntax to use?
* waffle makes a case for `become`
* current approach of requiring matching fn sigs, is that reasonable?

nikomatsakis: I stand by not wanting to accept an RFC with a huge syntactic question left out, but I also don't hate become.

scottmcm: I think josh was the one who cared the most about become, and he's not here today.

nikomatsakis: what are alternatives?

scottmcm: I do like the "hey waffle is an experienced compiler person"

nikomatsakis: maybe we want to leave a comment saying we're not sure about syntax, would prefer to figure that out before landing RFC, but if waffle wants to land it on nightly as an experiment, that is fine.

TC: signature matching?

scottmcm: I think this fits the "stabilize the easy part that we know will work" and expand later.

nikomatsakis: zero qualms about stabilizing and landing an RFC for a clear subset, e.g., same signatures.

### "Uplift `clippy::fn_null_check` lint" rust#111717

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

let fn_ptr: fn() = /* somehow obtained nullable function pointer */

if (fn_ptr as *const ()).is_null() { /* ... */ }

warn-by-default

follows my rule, it's not insta-UB, but pointless

tmandry: insta-UB to transmute a null ptr to a fn?

nikomatsakis: yes.

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

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

let _ = option_env!("HOME").unwrap();

garyguo: Does this need to be in the compiler?

scottmcm: maybe delegate to libs-api?

garyguo: the `fn_null_check` is not a bug

nikomatsakis: yeah but it suggests to me you may be casting a null ptr to a fn elsewhere, so it's tied to a bug

scottmcm: not sure "this could be done better" meets the bar

lokathor: similar to spelling convention

scottmcm: yeah but that affects your public API and affects reliability (e.g., confusion between a variant or a value)

nikomatsakis: I agree, I feel differently because of those reasons

scottmcm: I'd love to see a lang proposal for attributes you can put on things and how to redirect.

nikomatsakis: I like that, I'd rather see a mechanism of this kind. I don't think it makes sense to approve one-off lints for stdlib, but if we can give a mechanism that applies to the whole ecosystem, maybe makes sense.

lokathor: so if you have a fn that returns `Option<T>`, could have an attribute that says, if this is unwrapped, use this other function?

tmandry: I'd prefer for something where you can write patterns that clippy matches when it uses your crate.

scottmcm: I also don't know exactly what it should look like. I see all the lints that are useful and good (e.g., `step_by(0)` will always panic), but I don't think rustc should implement all these lints manually.

nikomatsakis: I say we reject this one and say we'd rather stick to bug-oriented lints for rustc itself.

scottmcm: I'm not convinced that "you could write this differently" meets rust's warn-by-default PR.

nikomatsakis: this lint by itself doesn't have much value. clippy has a bunch of lints that collectively have value, so either we move them all to rustc, which I don't want to do, or else we add a mechanism.

### "Uplift `clippy::cmp_nan` lint" rust#111818

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

Definitely a bug.

nikomatsakis: Deny by default seems a bit strong, not UB...

nikomatsakis: I think it should be same as `if x <= 255`?

I propose we do warn then.

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

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