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

# T-lang meeting agenda

* Meeting date: 2021-06-08

## Attendance

* Team members: Josh, Scott
* Others: Mara, Jane, Mark

## Meeting roles

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

## Scheduled meetings

* june updates and structural equality?

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

* Blocked on Niko's action item

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

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

* Caused by desire to move `trait Error` into `core`, which causes coherence errors today, as the compiler does not know that `&str: !Error` is a stable guarantee.
* Proposed implementation would allow for an easy extension to negative where bounds (where the negativity is specifically known due to an explicit impl, not a global search).
* but not committing yet
* For now just a coherence change
* Concern: both positive and negative trait impls allowed?
* seems like generally this is working
* Generally positive, not comitting to anything yet.

## PRs on the lang-team repo

* Nothing new to discuss here, discussed at meeting last week

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

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

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

* Do we prefer the shorthand to the full target specification?
* Is it best to cancel the FCP or to let things sit for now
* Inclination to let things sit for the time being.
* Previous discussion around "not full std implementation" or something along those lines.
* There's not an obvious reason that we need to move ahead with this RFC given that there's nothing strictly enabled by the RFC today.
* No rush to push forward a convenience syntax.
* There is a note that some cases, e.g., i586 and i686 are not distinguishable in cfg. Is possible with build scripts.
* Mara: If there is a limited set of targets then you may want the literal target triple without needing to translate
* Action item: Josh to leave feedback on the thread that there's some desire for a more complete examination of options

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

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

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

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

## Active FCPs

* no thoughts in this meeting

### "Type-changing struct update syntax" rfcs#2528

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

### "RFC: Supertrait item shadowing" rfcs#2845

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

### "Re-add support for parsing (and pretty-printing) inner-attributes in match body" rust#85193

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

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

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

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

* P-critical for a bunch of teams, the criticality is mostly not on T-lang.
* min_specialization allowing this is a bit unfortunate
* we may want some formal model or otherwise to identify
* using rustc_unsafe_specialization_marker
* there is not a performance-neutral fix for the standard library, which makes it in some sense a T-lang problem, but otherewise not so much

## Nominated RFCs, PRs and issues

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

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

* New version of extensive past discussions, including a few past RFCs. Discussed recently on Zulip.
* `let refutable_pat = X else { ... diverging_expr }`
* has been discussed fairly extensively
* A nice example: https://github.com/rust-lang/rust/blob/e4a60327063e82413eed50a10df3b7d19b77bda0/compiler/rustc_mir/src/transform/deaggregator.rs#L29-L34

let (lhs, kind, operands) = match stmt.kind {
    StatementKind::Assign(box (lhs, Rvalue::Aggregate(kind, operands))) => {
        (lhs, kind, operands)
    }
    _ => bug!(),
};

* a few clarifications being suggested to the text, but nothing too major.
* Q: Open question on expr with block or expr without block for the `X` part.
* Josh: generally in favor of requiring a block here
* Is there non-syntactic problems here?
* Where and how bindings apply within the blocks
* `let Some(x) = x else { use(x) };`
* x could be the uninitialized value in pattern, the original x (if Copy), not permitted(?)
* current draft doesn't permit non-diverging expressions
* still need to decide which type the `x` has, though
* no real use case for the pattern x being uninit in this case.
* given that not-diverging is likely not best served by let/else, i.e., prefer match
* Is there a discussion in the RFC of these problems?
* Mention of alternative/future change of non-diverging exprs in else, but that it would be backwards incompatible

let Ok(v) = x else {
    let Err(e) = x; // should this work?
};

* ^ that is typestate, which I really don't want, but I can imagine that someone might want to be able to do that.
* Future-compatible, could always add this as a future language extension
* But it's also ok to just say "you should use a `match`"

let v = Ok(3);
let Ok(3) = v;

* ^ in theory could be allowed

let Ok(v) = x else {
    // do something, then ...
    x? // should this be treated as diverging?
};

* people may think this should work, but just more broadly useful
* doesn't feel like it should be special cased to this case
* Action item: Josh to capture a comment about typestate.

* does not seem that there's extensive discussion of problems on the thread so far
* should we provide rustfmt guidance?
* may play into readability concern, even though generally we don't put this in RFCs
* but precedent of .await suggests maybe not necessary to discuss in the RFC; seems good to discuss before stabilization though.
* could be good addition to the stabilization checklist

* potentially amenable to one-wordish same-line divergence, e.g., `let Some(x) = y else panic!();`

Is there a way to get the other variants from a function call?

let Ok(x) = f() else {
    // access the result of f()?
    //  no
};

The potential `else match` future version of that would be

let Ok(x) = f() else match {
    Err(e) => ... e ...
};

which doesn't need typestate since the whole construct could desugar to a single `match`.

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

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

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

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

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

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

### "Deny float matches" rust#84045

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

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

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

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

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

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

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

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

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

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

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

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