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

# T-lang meeting agenda

* Meeting date: 2021-06-22

## Attendance

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

## Meeting roles

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

## Scheduled meetings

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

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

* Still a pending action item

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

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

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

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

* `trait Foo: Bar`, `&dyn Foo` -- can't get a `&dyn Bar` without gymnastics
* not subtyping, a coercion
* adjust vtable from `Foo` to `Bar`
* in the future:
* if we had `dyn Foo + Bar + Baz`:
* upcasting to arbitrary subsets `dyn Foo + Baz` would either require a "really wide pointer" or have a lot of subsets
* however we do want to preserve that
* `&dyn (Foo + Send)` should be upcast-able to
* `&dyn (Bar + Send)`
* presentation note:
* `Foo` and `Bar` change roles in the proposal at some point
* things we are not committing to:
* layout of vtables, just saying that the compiler is capable of converting in between them
* implementation concern:
* if we are naive (which we probably will be), size of all vtables will increase (but it could be optimized)
* conclusion:
* Josh seconded!

## PRs on the lang-team repo
### "Initial draft of copy ergonomics design note" lang-team#62

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

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

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

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

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

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

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

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

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

## Proposed FCPs

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

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

* Niko to take up with oli (acton item)

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

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

* Still open discussion about how the details should work
* Last meeting we said that we wanted a shorthand alternative
* There is a new discussion around target aliases
* For example, some folks use `x86_64-pc-linux-gnu`, and it'd be nice to be able to use one as an alias for the other
* For that to work, we would need a concrete answer for how that behaves in Rust
* We can define an alias and say that "target vendor" always shows up as unknown even if you pass pc
* Is that also true if you match the whole target string?
* Niko: Feels like scope creep, do we have to decide this now?
* Mark: Kind of true that we don't, but we did have them for a few cycles, for one specific target. But `x86_64-sun-solaris` and `x86_64-pc-solaris`. But it was reverted.
* Josh: we did that for backwards compatibility after accidentally changing name, right?
* Mark: Not important
* Mark: Agree that it feels like scope creep, and this feature doesn't do anything different than what we already have available today. Doesn't feel like this RFC is changing anything.
* We already have the "longhand" form of the variables available today.
* https://github.com/rust-lang/rust/pull/61761
* We don't need to sort this out *before* accepting this RFC; we just need to commit to deciding that if we add target aliases.
* Conclusion:
* Niko to drop concern about matching the entire target string
* 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 at that time.

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

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

* Forward progress is being made
* Currently in FCP to lang + libs-api
* Action item: lang team members to review

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

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

* Same as before

## Active FCPs
### "Support forwarding caller location through trait object method call" rust#81360

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

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

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

Action item: Niko to create charter or whatever :)

## P-critical issues
### "iter::Fuse is unsound with how specialization currently behaves around HRTB fn pointers" rust#85863

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

* Not P-critical for lang, just libs/compiler
* But libs would appreciate help and/or progress

## Nominated RFCs, PRs and issues
### "New RFC: Collection Transmute" rfcs#2756

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

* [Not a lang concern](https://github.com/rust-lang/rfcs/pull/2756#issuecomment-701533414)

### "New trait: core::convert::IntoUnderlying" rfcs#3046

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

* Been discussed async; moving in a slightly different direction
* Instead of `IntoUnderlying`, moving to "as repr", so you can convert to the discriminant type that was declared
* May eventually want lang input on this, take a look at this [summary comment](https://github.com/rust-lang/rust/pull/81642#issuecomment-862673931) and chime in if you have any concerns.

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

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

* :tada: from Josh
* Fallible let binding patterns with a fallback else that must diverge

let Some(x) = expression else { ... };

* Alternatives and things are thoroughly captured
* Felix: In the summary it says "expression" is "expression without block", what does that mean?
* Josh: We disallow things that take braced blocks, like `if/else`, so that you can't end up with `let Some(x) = if expr { ... } else { ... } else { ... }`
* Niko: Is this referencing the existing nonterminal, the condition of an `if`?
* Josh: I think so, but confirm.
* Felix: I'll read the RFC.
* Josh: Anyone see a reason for me not to rfcbot merge this?
* Mara: I didn't see a reply from Esteban, but he usually has an opinion about what works well for diagnostics.
* Josh: Let's cc him into the thread.
* Josh: /me types loudly and does rfcbot merge

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

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

Already discussed

### "Support forwarding caller location through trait object method call" rust#81360

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

Already discussed

### "Allow deriving Into and TryFrom for primitive enums" rust#81642

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

* This is the one that is moving to `AsRepr` instead, likely to proceed

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

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

* We've discussed this a number of times
* Question is whether there is a conflict between slice patterns and range patterns
* Think it was resolved via Zulip, but was it captured on Github?
* Niko:
* I believe we decided to keep the patterns embedded
* But the PR author preferred to keep it unstable and didn't make the change
* Josh: Should we have a direct async conversation to discuss it a bit further?
* Niko: Seems good. In the end this feels like an edge case so I could live with holding it unstable, though I don't think I would want to give up on the natural pattern syntax.

### "Deny float matches" rust#84045

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

* Blocked on structural equality design meeting

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

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

* Last time we discussed it, concerns were raised
* [Summary from prior meeting](https://github.com/rust-lang/lang-team/blob/master/minutes/2021-05-11.md#add-expr202x-macro-pattern-rust84364)

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

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

dtolnay proposing

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

* Question:
* Is this re-adding support or did we never have it? Unclear.
* Current state:
* modules/extern-blocks/functions since 1.0
* traits (https://github.com/rust-lang/rust/pull/68728)
* struct/enum/union foo not supported
* Consistency:
* Two "groups" of things
* Traits have items, like modules etc
* Josh: Exists for modules because there is no way to place things outer, but for struct/enum/union I'd just as soon have people write it on the outside and not have a choice.
* If this is a thing people *expect* to do, we could add a rustfix to move it.
* Mark: dtolnay's argument is that placing it inside makes sense if it is expanding to the "variants" of a struct (stylistic)
* petrochenkov doesn't like it
* Mara: this would also apply to putting methods inside structs
* adding things on the inside into the comma-separated list feels weird
* Josh: I think petrochenkov is saying
* we support inner attributes on places where items exist
* match is a funny special case because back-compat
* https://github.com/rust-lang/rust/pull/84414#issuecomment-826150936
* Niko: I think there's another, more 'syntactic' view that says "any time I'm inside a braced thing, I can put inner attributes there"
* Josh: I think I would explain it as "here is a special case for attaching something to the module that consists of your entire file, ignore the other places that it might work"
* Felix: I'd like to know if the community views things the josh way -- maybe we could have a lint that discourages use of inner attributes except in modules? Or some other way to take temperature?
* Others: good point! interesting idea.
* Consensus:
* 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

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

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

* Special lang item to support
* `impl<T: Default, const N: usize> Default for [T; N]`
* `impl<T> Default for [T; 0]` -- exists today
* Today we have
* `impl<T: Default> Default for [T; N]` -- hardcoded from 1..=32
* Josh: Do we support `impl<T> Default for [T]` today (generating an empty slice)?
* no, because `[T]` is unsized. we don't have `&[T]`/`&mut [T]` impls either though.
* Niko: what it comes down to:
* In worst case, we are forever committed to having `array_default_hack` and some notion of marker traits. If we're ok with that because this pair of impls is valuable enough (and I may be) then we should just do it.
* However, the ideal would be that we extend specialization to support this, or perhaps some other mechanism (`where N != 0`).
* Josh: In theory we could have some kind of "conditional where clause" like `if N != 0 { T: Default }`.
* Niko: probably equivalent to `where N != 0`.
* Conclusion:
* fcp merge, Niko to write-up

### "add back support for inner attributes on non-block expressions?" rust#84879

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

* Felix: I believe this is addressed by PR #85193
* Conclusion: Denominate, adequately addressed by #85193.

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

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

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

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

### "Stabilize bindings_after_at" rust#85305

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

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

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

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