---
title: Triage meeting 2022-04-05
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-04-05

## Attendance

* Team members: pnkfelix, Josh, Scott
* Others: Mark, David Barsky, Jane, compiler-errors

## Meeting roles

* Action item scribe: Mark
* Note-taker: scott (first 45 minutes)

## Potential scheduled meetings
- "Structural equality" [lang-team#94](https://github.com/rust-lang/lang-team/issues/94)
- "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97)
- "Dyn upcasting, safety considerations" [lang-team#119](https://github.com/rust-lang/lang-team/issues/119)
- "Const eval overview" [lang-team#131](https://github.com/rust-lang/lang-team/issues/131)
- "Lint policy" [lang-team#132](https://github.com/rust-lang/lang-team/issues/132)
- ""RPITIDT"" [lang-team#144](https://github.com/rust-lang/lang-team/issues/144)

## Announcements or custom items

(Meeting attendees, feel free to add items here!)

## Action item review

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

## Pending lang team project proposals
### "Deprecate target_vendor " lang-team#102

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

### "Support platforms with size_t != uintptr_t" lang-team#125

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

### "Positional Associated Types" lang-team#126

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

### "Interoperability With C++ Destruction Order" lang-team#135

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

### "inner crates, aka multiple crates per file" lang-team#139

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

Josh: Are you still excited by this, Felix?

Felix: *hesitantly* Yes?

Josh: Are you enthusiastic enough to get buy-in and a plan?

Felix: I dunno? I've said what I have to say.

Josh: We have a process for seconding, but not for "hmm, it hasn't gotten a second". What does deciding "I guess not" look like?

Mark: Didn't we have something for this?

Josh: We discussed time-based?

Mark: Didn't Niko post a PR to the lang-team repo adding a process?

Scott: How should we weigh the "that sounds cool vs I'm scared about the implication"

Josh: If this is about an experiment, then the second might be appropriate? If someone feels like they're not sure but an experiment might convince them, it might be appropriate to second. Also, thanks Mark for linking the process doc.

Felix: The only updates I might want are to split out the proc macro case. That would still help the non_exhaustive cases, for example.

Josh: That might make me more interested in doing it.

Scott: Though I don't know how essential the "nice for examples" use is.

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

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

### "Add `#[deprecated_safe]` attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

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

### "Async fns in traits" lang-team#150

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

### "extern macro!(ABI) fn" lang-team#151

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

(moved to FCP close 14 days ago, can we close?)

Josh: New comment with a similar request, but the macro solution should still work here.

Josh: Could someone verify, and then summarize and close? With a playground demonstrating a macro.

Felix & Scott: I don't want to make that playground.

Scott: bravely volunteers to summarize

## PRs on the lang-team repo

None.

## RFCs waiting to be merged
### "New Rust attribute to support embedding debugger visualizers" rfcs#3191

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

Josh: This is ready to merge, anyone interested?

Felix: I can merge this.

David: What about the approach of having MIRI evaluate a `Debug` or similar? Is that just too far off?

Josh: That'd be a large non-Rust project; it's an interesting idea but not a short-term solution. In the mean time we need something that works with what debuggers actually do, but that would definitely be a nice project -- albeit perhaps a non-Rust project. Generally we have to balance making rust work with other things vs other things working with rust, and this is a good example of that.

David: I might know some lldb resources who could be interested.

## Proposed FCPs

**Check your boxes!**
### "RFC: Add `target` configuration " rfcs#3239

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

Josh: This is a updated version of a previous one we talked about, resolving previous issues. Please take a look and see whether you have any new concern.

Felix: is it an and/or?

Josh: It should be an `all`, but if the RFC doesn't seem clear in that regard, please make a concern or a GitHub suggestion.

David: Does this have any interaction with the `link` attribute?

Josh: oh, since it has some built-in cfg?

David: Windows-sys does some odd things that this might help with

Josh: Check how it interacts, and make a suggestion.

David: will take a look today or tomorrow

### "Tracking Issue for const offset_from (const_ptr_offset_from)" rust#92980

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

### "Check if call return type is visibly uninhabited when building MIR" rust#93313

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

### "Stabilize `let else`" rust#93628

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

Felix: This is still blocked on temporary lifetimes.

### "Stabilize `let_chains` in Rust 1.62.0" rust#94927

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

Scott: What about the interaction with let else for this

Josh: Definitely not a let-else *inside* a chain. The other way around is a more reasonable question, but we can consider at a later time. But if there's a 1-way door we're missing, raise it.

Scott: Ok, that resolves my

Felix: What about this PR? https://github.com/rust-lang/rust/pull/94974

Josh: It's testing both.

Felix: What's something that could be reasonable?

Scott: I think this one coulse potentially be reasonable

let Some(b) = a && let Some(c) = b else {
    return;
};

Josh: An `else` makes it infallible, which makes having it in a condition make not sense any more.

Felix: I'm convinced we're not going through any 1-way doors here.

## Active FCPs
### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

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

### "[`let_chains`] Forbid `let` inside parentheses" rust#95008

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

### "Deprecate target_vendor " lang-team#102

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

### "Positional Associated Types" lang-team#126

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

### "Interoperability With C++ Destruction Order" lang-team#135

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

### "Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion" lang-team#147

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

### "Async fns in traits" lang-team#150

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

### "extern macro!(ABI) fn" lang-team#151

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues

### "Edition Based Method Disambiguation: Preventing inference ambiguity breakages with extension trait methods" rfcs#3240

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

Josh: I think this is ready for consideration.
Josh: Was tempted to rfcbot merge it, but wanted some informal double-check here first.

yaahc: Its either ready or very close. Some questions, like how colud this be extended to nonstd. Parallel proposal that hasn't materialized from Mara with ideas about filtering visibility of items based on rust-version field. Can express "only support rust 1.45" and you wouldn't even *see* the item on later versions. But if that were the *only* solution, then bumping Rust version is *still* a potentially breaking change. So the idea proposed in RFC PR 3240 is still worth considering.

Josh: Can see the benefits of that, but concerned about the implication of breakage in bumping Rust versions.

yaahc: Also an autoref behavior question, very much open question. How does this disambiguation interact with autoref, and how that can be used to replace how array IntoIter is handled in an ad-hoc manner today.

yaahc: Its not just array IntoIter, there are other similar cases that could likewise benefit. But we still need to figure out whether that works.

Josh: Is that a blocker for the RFC design?

yaahc: Not sure. May have to try it to see.

Josh: Might be worth updating RFC with those two additions, and comment in zulip with suggestion on how to move forward to resolve the autoref question (i.e. should that be resolved prior to experimentation, or if it could be resolved *via* experimentation.)

Josh: I want to reduce team scope to just T-lang, not T-compiler and T-libs

yaahc: I wanted T-compiler to be aware of it and provide feedback on the approach

pnkfelix: I think the answer there is to post a T-compiler MCP after T-lang has signed off on RFC itself.

### "Simple postfix macros" rfcs#2442

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

Josh: This has been updated to incoporate all feedback, especially with autoref mechanism to allow calls on all kinds of chains.

### "Introduce `enhanced_binary_op` feature" rust#93049

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

Josh: Could we get more clarity on the ask here?

Some lack of clarity on what the change was related to `||`; the original ask was just related to handling of `&&`.

### "Allow using `for<'a>` syntax when declaring closures" rfcs#3216

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

### "Refined trait implementations" rfcs#3245

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

### "Check if call return type is visibly uninhabited when building MIR" rust#93313

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

### "Allow `impl Fn() -> impl Trait` in return position" rust#93582

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

### "Stabilize `let_chains` in Rust 1.62.0" rust#94927

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

### "Enforce that layout size fits in isize in Layout" rust#95295

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

### "make unaligned_references lint deny-by-default" rust#95372

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

### "Specify guarantees for repr(rust) structs" reference#1152

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

### "Clarify guarantees provided by repr(packed)" reference#1163

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