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

# T-lang meeting agenda

* Meeting date: 2021-06-15

## Attendance

* Team members: nikomatsakis, joshtriplett, cramertj, scottmcm, pnkfelix
* Others: simulacrum, m-ou-se

## Meeting roles

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

## Scheduled meetings

### Upcoming

From [planning meeting notes](https://hackmd.io/C0jvelJoQX2T9N5HLP2pCw?edit):

* June 16 -- Structural equality <-- Niko had no time for this, deschedule
* Canceling this meeting
* June 23 -- Possible: Atomic follow-up <-- Felix?
* June 30 -- Lang team process proposal <-- nikomatsakis still plans to prep

Plan:

* Cancel June 16
* Evaluate June 23 meeting next week based on progress (can swap topics)

### Already had these meetings

Need to close the issues, we should push minutes and notes.

- "Rust language "guiding principles"" [lang-team#91](https://github.com/rust-lang/lang-team/issues/91)
- "Generators planning" [lang-team#92](https://github.com/rust-lang/lang-team/issues/92)
- "May updates" [lang-team#93](https://github.com/rust-lang/lang-team/issues/93)

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

* Status: Niko started write-up, no progress since then.

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

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

* Status: Seconded.
* There is some interaction with specialization:
* The example here is *not* a specialization (`&str: !Error`) but it would be kind of nice if this "just worked".
* One could make the case that a "rounded" version of specialization might accept this case.

impl From<&str> for Box<dyn Error>> { }
impl<E> From<E> for Box<dyn Error>>
where
    E: Error, { }

* This case is expressing something different from specialization.
* But often the times that cramertj wants specialization isn't strictly "making a more specialized version", but rather some way to deal with overlaps that are either theoretically possible or just uninteresting.
* Josh has run into this case as well, where the compiler doesn't understand that there's no actual overlap. Josh would prefer to use negative impls to tell the compiler there's no overlap, rather than using specialization to say the "overlap" is OK.
* Mara: The negative impl allows you to augment the upstream crate by promising not to have overlap, whereas specialization lets the user deal with overlap if it occurs.
* Josh: Might you sometimes use negative impl in downstream crate?
* cramertj: Why not have str implement Error?
* Niko: seems like a good thing to to the project group, but I think it has to do.
* Niko: there are times you don't want to use specialization, because you don't want `default` on your items, e.g. for associated types.
* scottmcm: it's worth nothing that we could use this to replace some fundamentals, e.g. by making `str` not a function, so that we can make the closure traits not fundamental.
* Niko: right, it was done so that you can make arguments either a closure or a value
* Josh: Have we looked into what it means to fully generalize fundamental types?
* Josh: Is there still motivation for this if we merge core/alloc/std?
* Niko: Have been interested for some time, for things like "all Copy types, and Vec"
* Answer: yes, but less. Also it seems like that merge would take longer to make a reality than negative impls.
* ed.: same is true for specialization
* scottmcm: We could consider allowing negative bounds not by the absence of a positive impl, but by the presence of an explicit negative impl.
* This might enable some specialiation use cases as well.

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

**Assigned to:** pnkfelix

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

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

**Assigned to:** scottmcm

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

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

**Assigned to:** nikomatsakis

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

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

**Assigned to:** nikomatsakis

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

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

**Assigned to:** cramertj

## 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 for nikomatsakis to talk to const generics group.
* Has been over a year since we last checked boxes.

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

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

* Josh wanted shorthand syntax for matching specific components of the triple, rather than the full target triple.
* Mara: "For most cross-platform libaries in the ecosystem it's probably an antipattern to match on a specific target triple. But for other software it's quite common that it's built for two or three specific targets (e.g. a company making software for specific hardware). In those cases, it would be a lot more readable to match exactly on the few target triples that are supported, rather than having to translate those into separate components."
* Concern:
* people could over-specialize
* a lot of the interest was specific to wasm32-unknown-unknown
* Mara: it could happen that people are overly general by matching against more targets than they meant to, as well, right?
* I couldn't convince myself that matching all the parts might not accidentally match more than I meant.
* ,Niko: Why not support both?
* Josh: people might misuse the wrong thing
* Josh: I don't think this is likely to be a problem where you 2 of the 3 components. But there are platforms like arc, risc-v, etc where many details are wedged into those target strings (e.g., the ABI). We have logic to handle that in our parsed out version. Exposing the full target string then exposes all the squirelly little flags.
* Mara: But if that's specifically what I wanted?
* Niko: So why NOT do both?
* Mara: bikeshed to figure out the right split outs.
* Josh: What we have now is a split-out version but we don't have a shorthand to make it easier. People might match the target just for the brevity.
* Right now you would do `#[cfg(all(target_os=..., target_family=...))]`
* Niko: so we're just exposing those with a distinct syntax, right? So you can write `target(os=..., ...)`, so the bikeshedding has basically been done, right?
* Josh: Agreed. I'd be happy with "let's allow both and request the RFC specify the shorthand version".
* Mara: So you don't want to extend the set of things we parse?
* Niko: agreed, just make it more convenient to access, extending is a distinct RFC.
* Note: target_abi is https://github.com/rust-lang/rfcs/pull/2992
* Consensus:
* Allow matching exact target triple
* Introduce a shorthand syntax to access existing `target_xxx` variables, but not introduce any new such variables
* Action item: Josh to summarize consensus

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

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

* Continued progress towards implementing subset of accessible.
* Josh: not sure how much implementation energy there is at the moment, though.
* Niko: sounds like we need to write mentoring instructions
* Action item: nikomatsakis to add to the project board.

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

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

* Niko proposed FCP
* If you have it on the trait, is it required on the impl?
* Answer: no, can't make it a hard error, backwards compatibility.
* We could potentially warn on this.
* pnkfelix: I'm trying to understand the logic. In principle you could have some impls that don't use `#[track_caller]` because they don't need it and (with static dispatch, at least) don't want the extra parameter.
* Niko: perf hit seems theoretical.
* Josh: We've had PRs to add `#[track_caller]` to more methods, and for especially hot methods in the stdlib the perf test suite does see a difference.
* Felix: Not necessarily runtime cost, could be the compiler getting slower because it has more work to do.

### "Stabilize RFC 2345: Allow panicking in constants" rust#85194

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

* [Blocked on edition interactions](https://github.com/rust-lang/rust/issues/85194#issuecomment-852345377), afaik
* Should we close and encourage someone to come with a write-up?
* Josh: why is this a blocker?
* Niko: I don't like things working on rust 2018 that don't work in rust 2021
* Mara: We don't have a way to migrate
* Josh: what about panic with a string and no format arguments, can that work?
* Mara: that's exactly what we *undid* in Rust 2021 because it accepted too many things
* Josh: what about a function that only takes strings?
* Mara: that exists, `panic_str`, but it doesn't access any arguments like `{}`.
* Mara: we could expose this function, but I'd rather not
* Mara: `panic_any` only exists in std and not in core
* and we don't want to make const panic incompatible with with no-std
* Josh: do we have to CLOSE this, or can we just leave it as blocked on this concern?
* Niko: I'd rather just record that we are in support and close the issue. Just a procedural note, but I think the purpose of this issue was to decide whether to stabilize NOW (not at arbitrary points in the future).
* Josh: Support recording consensus and then closing, to make the path clear for the future point where we have a way to do a const panic without the format machinery (or when the format machinery works in const).

## Active FCPs

### "Ignore derived Clone and Debug implementations during dead code analysis" rust#85200

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

* Impl detail raised: [it'd be nice if this were driven by a custom attribute.](https://github.com/rust-lang/rust/pull/85200#issuecomment-859980356)

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

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

* Listed above

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

* Recent compiler team meetings proposed to back out some but not all specializations.
* Actual problems seem fairly unlikely but this is clearly a blocker to resolve or consider for stabilization specialization.
* Proposal: No further action needed at this time, we should do an overall assessment of unsoundness at some point in future and triage appropriately.

## Nominated RFCs, PRs and issues

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

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

* pnkfelix opened a PR here for match, right?
* [PR #85193](https://github.com/rust-lang/rust/pull/85193): "Re-add support for parsing (and pretty-printing) inner-attributes in match body"
* If so, can we close

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

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

* Active discussion, Josh seems to be pushing
* Niko: Added to project board.

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

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

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

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

* Is this a lang concern?
* scottmcm: I don't think so, except in that it might impact our feelings on things like `as`.

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

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

* Question is whether to permit `..` at the top-level of a slice pattern
* Do we want `[..3]`, for example?
* `let [octobyte 0..8, rest @ ..] = byteslice;`
* Current status: PR leaves that corner case as unstable.

### "Deny float matches" rust#84045

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

* Blocked on structural equality meeting.

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

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

* Waiting for pnkfelix to request specific grammar change or something like that?

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

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

* Pending for some time with no feedback
* We do now support `match { #![foo] ... }`
* Thoughts?

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

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

* [Latest status unchanged](https://github.com/rust-lang/rust/pull/84838#issuecomment-832273599)
* What do we need to do to move this forward?
* Given the uncertainty around specialization, Niko is feeling a mite nervous.
* However: even in the absence of specialization, is this worth a "special case" to support? Arguably yes.

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

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

* Behavior here is rather 'historical', but useful sometimes
* [Mark suggests an RFC is required](https://github.com/rust-lang/rust/pull/85298#issuecomment-848401703)

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

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

## (Deprioritized or blocked issues from the list above)

### "Stabilize RFC 2345: Allow panicking in constants" rust#85194

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

* (See above)

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

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

* requires detailed review, skip

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

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

* Pending FCP, see above.