---
title: Triage meeting 2021-06-29
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-06-29

## Attendance

* Team members: nikomatsakis, scottmcm, Josh, Felix
* Others: simulacrum, Mara

## Meeting roles

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

## Scheduled meetings

- "Lang team process proposal" [lang-team#99](https://github.com/rust-lang/lang-team/issues/99)

## Action item review

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

## Pending lang team project proposals
### "MCP: Allowing the compiler to eagerly drop values" lang-team#86

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

* Pending action item: Niko to complete his notes

### "negative impls integrated into coherence" lang-team#96

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

* FCP has expired, needs to be converted and added to project board

### "Trait Upcasting" lang-team#98

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

* 7 days into FCP

### "Discontinue meeting recordings" lang-team#100

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

* 5 days into FCP
* Reasoning
* Recordings can be stifling or exclusionary
* Having everything be public can be exhausting, have to watch your wording, particularly if making jokes
* Occasionally people will dig up time codes to explain the reasoning
* People don't want to lose control of their recordings
* Other teams within Rust governance are not recording their meetings for the most part, with some exceptions
* e.g., library team does not, compiler team does not (and some members of both have concerns)
* Minutes with reasoning should suffice, and if not, we should do better
* Difficult to discuss sensitive topics
* Sometimes these topics arise independently
* Uploading and maintaining records is a time investment
* Questions raised in the thread
* Design meetings
* May be more valuable here-- for triage, it's clear that we ought to be capturing our reasoning and limited the amount of time we spend on any individual topic
* Exception: if we do a talk where someone has prepared a "broadcast", we can decide for any given meeting to record
* Alternatives
* Private recording
* Recordings available to the lang team
* Setting aside time for private conversations at the end
* What do we lose
* Engagement, potentially, for folks who are not into blog posts
* We could recover this in other ways, e.g. a podcast sort of thing
* Could connect to existing podcasts for that

## PRs on the lang-team repo

* Action items noted for relevant PRs; nothing to discuss

### "Initial draft of copy ergonomics design note" lang-team#62

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

* still needs work to revise (waiting on Mark)

### "Autoref/autoderef for operators" lang-team#63

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

* Waiting on Scott

### "Auto trait design note" lang-team#69

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

* Waiting on Niko

### "Add design notes for function-type `Default` implementation discussion" lang-team#71

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

* Waiting on Niko

### "Add draft of variadic notes" lang-team#76

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

* Waiting on author to revise after comments by Taylor

## Proposed FCPs

**Check your boxes!**
### "Calling methods on generic parameters of const fns" rfcs#2632

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

* Pending action item: Niko to resolve

### "RFC: Add `target` configuration" rfcs#2991

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

[Conclusion from last meeting](https://github.com/rust-lang/lang-team/blob/master/minutes/2021-06-22.md#rfc-add-target-configuration-rfcs2991):

* Niko to drop concern about matching the entire target string (done)
* Josh will leave his concern in place regarding shorthand until is added
* Conclusion:
* We expect the "combined string" to match the behavior of the "longhand" variables.
* But when we introduce an alias we can decide the specific values of the "longhand" variables

This meeting:

* Discussion about what to do in the case of aliases; settle this as part of the discussion introducing the alias.
* pnkfelix: Would "pc" be mapped to unknown in *all contexts*? Or just in the case of that one target triple?
* joshtriplett: The proposal (if accepted) would map the entire target triple, not just the component

### "`#[derive(Default)]` on enums with a `#[default]` attribute" rfcs#3107

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

Pending FCP to allow `#[default]` to select the variant when deriving `Default`:

#[derive(Default)]
enum Option<T> {
    #[default]
    None,
    Some(T),
}

* Note that, in this case, `#[default]` is only allowed on variants with no data and it does not include a `T: Clone` bound for generics
* Scott: There is an inconsistency with other derives, all of which would like to be able to exclude the `T: Clone` bound, why separate this case?
* Mara: This one is specific to a particular variant, and the behavior would *always* be wrong
* Combined lang/libs FCP

### "RFC: let-else statements" rfcs#3137

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

* In FCP; had a concern (ambig grammar) that is now resolved
* Had a lot of discussion and these things are covered under alternatives
* Comments:
* [using postfix procedural macros could make it nice](https://github.com/rust-lang/rfcs/pull/3137#issuecomment-869451448)
* `let x = foo.unwrap_or_else! { ... }` -- only works for `Option` or `Result`, but this is useful for all kinds of enums, and also more complex nested patterns
* Niko would like this to work by allowing you to return from the closure, but that's another story
* scottmcm comment on this: https://github.com/rust-lang/rfcs/pull/3137#issuecomment-856375142
* With what I think is a nice examples of something that's not option/result
* How typical is this, is `match` so bad, shouldn't we just use a macro? (Aaron1011's concern)
* Scott, digging a rabbit hole:
* One might misunderstand this syntax:
* `let x = None else { 3 };` // x == 3. `??` in C#, `?:` in Kotlin
* You could imagine that `else` is like `None.unwrap_or(3)`
* "Yes"
* Josh: there has been conversation about this *sort of* thing in the past
* Some brainstorming about how this syntax will "feel"
* Also whether one can make a set of orthogonal features that all play nice with each other
* Meeting consensus:
* Allow FCP to continue
* General desire for clippy lints to help people migrate

### "Tracking issue for RFC 2523, `#[cfg(version(..))]`" rust#64796

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

* Still waiting on Josh's concern
* Nothing to discuss right now

## Active FCPs

### "Stabilize "RangeFrom" patterns in 1.55" rust#83918

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

* In FCP for partial stabilization
* Excludes patterns from slices:
* we've said in the past we would be ok to stabilize, but if PR author wants to hold back, seems ok

### "negative impls integrated into coherence" lang-team#96

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

* Existing action item: Niko to "merge" negative impl coherence https://github.com/rust-lang/lang-team/issues/96

### "Trait Upcasting" lang-team#98

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

* Seconded, 3 days out from fcp period finishing. No discussion needed just now.

### "Discontinue meeting recordings" lang-team#100

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

* Already discussed, see above

## Nominated RFCs, PRs and issues

### "Add `expr202x` macro pattern" rust#84364

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

* No change, still waiting on pnkfelix to sharpen request I believe --nikomatsakis

### "Allow struct and enum to contain inner attrs" rust#84414

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

* [Consensus from last meeting](https://github.com/rust-lang/lang-team/blob/master/minutes/2021-06-22.md#allow-struct-and-enum-to-contain-inner-attrs-rust84414):
* We shouldn't leave this open
* Some people have mild preferences one way, some the other
* Don't have a full quorum for the team here, wait a bit
* nikomatsakis was curious to get a "straw poll"
* nikomatsakis: Would like to allow macros in more places; this example would be even clearer like this, imo, and it would add more capabilities:

#[derive(Something)]
struct Foo {
    expand_members!()
}

* scottmcm: because it's all in the macro anyway, it could do arbitrary tokens too?

enum Foo { .. from header .. }

* Consensus:
* Lacks a strong champion
* Several people are confused (others not)
* Prefer to explore allowing macros in that position, or other solutions
* Josh to open action item

### "implement `Default` for all arrays" rust#84838

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

* [Consensus from last meeting](https://github.com/rust-lang/lang-team/blob/master/minutes/2021-06-22.md#implement-default-for-all-arrays-rust84838):
* ~~fcp merge, Niko to write-up (didn't happen yet)~~
* Concern about maintenance from a libs perspective:
* This is very complex and hacky
* Would we really want to maintain it long term?
* Concern: if this is opened for Default, won't we be getting PRs for all the other cases?
* Answer: quite possibly!
* Josh: to separate out, from a *lang team perspective*, we don't object in particular to this hack
* But the libs team in its role as implementor is free to say this is too hacky to maintain.
* Niko: I'm convinced by that, it was a close call
* We'd be happy to review a proposal that puts more into the lang/compiler to make this more maintainable from a library perspective.
* *New* action item to fcp close:
* nikomatsakis can do it

### "Check for union field accesses in THIR unsafeck" rust#85263

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

* Next step:
* Someone to review and prepare summary-- nikomatsakis is assigned but hasn't had time

### "Fix how allow/warn/deny/forbid `warnings` is handled" rust#85298

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

OP:

> This pull request attempts to fix #41941, fix #70819 (the command line part, which is why the issue was reopened), and fix #75668. The current implementation of `warnings` (as in `-D warnings` or `#[allow(warnings)]`) is "lazy" in that `warnings` is not considered by the linter until it is about to emit a warning, in which case it checks whether an allow/deny/forbid of `warnings` is in scope and up-/downgrades the warning accordingly.
>
> The problem with this approach is that one can never get an (e.g.) `#![allow(warnings)]` _out of scope_ again except by shadowing it with another `#[warn/deny/forbid(warnings)]`; ideally, though, one would also want more fine-grained control, such as
> ```rust
> #![allow(warnings)]
>
> fn main() {
> #[warn(unused)]
> let a = 5;
> }
> ```
> which compiles without warnings and errors on current nightly but causes a warning with my changes (as one would expect, I would argue).
>
> ...
>
> I've also worked on the command line arguments: Calling `rustc` with `-F warnings -A unused` works without errors or warnings on current nightly; with my changes, I get
> ```
> warning: allow(unused) incompatible with previous forbid
> |
> = note: `#[warn(forbidden_lint_groups)]` on by default
> = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
> = note: for more information, see issue #81670 <https://github.com/rust-lang/rust/issues/81670>
> = note: `forbid` lint level was set on command line
> ```

Mark:

> I don't think this patch can be accepted as-is because it breaks the common (though sort of "incorrect" from first principles in some sense) pattern of specifying `#![warn(...)]` or `-W...` on some lints, perhaps additional, perhaps replacing allow at 'higher' levels, and then using -Dwarnings to change all of them to errors, independent of why they're being emitted. To some extent, I guess this desire is basically a "inverse cap-lints", but not quite https://github.com/rust-lang/compiler-team/issues/434.
>
> I suspect changes here are going to want to go through an RFC or at least some sort of broader consideration (nominating for @rust-lang/lang), because it seems like the design space here is somewhat broad and there is likely some amount of breakage to consider.

* Niko's proposal:
* Make this into an active project, if there is a liaison

### "Stabilize bindings_after_at" rust#85305

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

* [Stabilization report](https://github.com/rust-lang/rust/issues/65490#issuecomment-841999009)
* TL;DR:
* We removed this back in the old AST borrowck days as a 'quick hack' to get to 1.0
* The MIR borrow checker can handle it no problem
* nikomatsakis went ahead and [did a FCP merge](https://github.com/rust-lang/rust/pull/85305#issuecomment-870758731)

### "Stabilize `const_fn_transmute`, `const_fn_union`" rust#85769

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

[Stabilization report](https://github.com/rust-lang/rust/pull/85769#issuecomment-854363720):

> [RFC 3106](https://rust-lang.github.io/rfcs/3016-const-ub.html) permits undefined behavior in const evaluation, with the summary being the following:
>
> > Define UB during const evaluation to lead to an unspecified result or hard error for the affected CTFE query, but not otherwise infect the compilation process.
>
> This pull request stabilizes the `const_fn_transmute` and `const_fn_union` feature gates. Both `transmute` and `union` are presently stable in `const` and `static` statements, but not in `const fn`. This PR is the first to invoke the aforementioned RFC to my knowledge. These features are relied upon in the test suite, though strictly speaking this is somewhat unnecessary (as behavior when UB is present is by definition not defined). Some cases throw a compile-time error while others will succeed and have undefined behavior.

### "Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable" rust#86492

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

struct AssocFn;

impl AssocFn {
    #[no_mangle]
    fn foo() {}
}

* This code doesn't have `foo` exported
* Should it?
* petrochenkov thought [perhaps it should be an error](https://github.com/rust-lang/rust/pull/86492)
* No evidence of whether this is used in the wild or not