---
title: Triage meeting 2022-06-28
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-06-28

## Attendance

* Team members: Josh, Niko
* Others: Mark

## Meeting roles

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

## Announcements or custom items

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

### Backlog bonanza!

Tomorrow is backlog bonanza.

### Generic Associated Types

* Niko did a deep dive showing some of the ways
* Niko's plan to go forward
* Start a pre-FCP with the following concerns identified
* For lang team:
* Do we want to expose GATs directly or only use them internally to enable other features?
* In other words, when you ignore async functions, RPITIT, and other such features: are GATs still worthwhile?
* Assuming we want the feature, is it worth stabilizing it now should we delay because of the known shortcomings and their potential impact on users?
* Helpful to answering this question:
* Estimates of how quickly we can address the various shortcomings
* For types team:
* Are we confident we can address the known shortcomings without backwards incompatible changes?
* Are we closing off any possible routes by stabilizing now?
* Depending on how people feel, we can decide whether we want to have a discussion meeting etc

### GCC Rust proposal

simulacrum: GCC Rust proposed potentially shipping in some sort of experimental phase w/o a borrowck

joshtriplett: I've been thinking about the policy question for alterantive Rust implementations for some time
* e.g., when do we collaborate on fixing bugs and the like
* and when do we let them call themselves Rust

nikomatsakis: is it something we can make independent progress on? (i.e., a policy that is not talking about trademark legal questions)

joshtriplett: Agree, have some drafts. I do believe that we should have a policy that says "you're not a Rust impl if you don't implement (e.g.) borrow checking or 'the full scope of the Rust language'". It's not necessarily a problem to be out of date, implementing an older Rust. If however, you're *always* out of date (don't have futures that are newer than 3 or 4 years old), I'm not sure we want to call that a Rust implementation. I'd like to avoid bifurcation, where there's pressure to support implementation X and hence to avoid features Y. I'd like to have a way where we are comfortable saying "that's not a Rust impl" in a way that makes community comfortable saying "oh, then we don't need to support that". If we say "yes, that's absolutely a Rust impl" then there's more pressure to compile on it. That's the fundamental dividing line.

nikomatsakis: I think having a general policy is a great idea, but it'd probably be good to start by considering the GCC Rust question *specifically*, since that's a simpler problem.

joshtriplett: Agreed, and last I heard, they agreed it's not reasonable to develop w/o a borrow checker. My understanding is that they want to get merged into GCC as something experimental that they don't recommend people use (yet). But we should find out how they want to position this, how they intend to communicate that.

Historically they've been calling themselves gcc-rs, which I think is preferable to Gcc Rust for a variety of reasons. This separates out the "whether this is a Rust implementation" question. Having something that implements gcc-rs that implements some subset of Rust.

nikomatsakis: Yeah, I actively want to encourage people to build experimental and new Rust compilers. gcc-rs is an extreme example but I'm also thinking of things like academic efforts. It does seem better though if they adopt a naming convention like -rs to help clarify for users.

joshtriplett: Yes, would want to clarify that intention is not to discourage experimentation, learning, innovation. Seems similar to target tier policy, in that the target tier policy is about "When is it ok to ask other people to support your architecture"; this is about "when is it ok to ask rust community at large to support your project". There's a failure mode in open source where this work gets offloaded, sometimes. We should totally talk to them, in any case, they've so far been very helpful and open to discussion on this point. I'm more concerned about other projects in the future that could cause divergence in rust (multiple Rusts).

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

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

### "dyn* trait" lang-team#158

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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

### "Add const evaluatable `where const { <block> }`" lang-team#163

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

### "#[repr(Interoperable_2024)]" lang-team#165

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

## PRs on the lang-team repo
### "Note design constraints on hypothetical `DynSized`" lang-team#166

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

## RFCs waiting to be merged
### "Refined trait implementations" rfcs#3245

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

## Proposed FCPs

**Check your boxes!**
### "Stabilize `let else`" rust#93628

- **Link:** https://github.com/rust-lang/rust/pull/93628
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383585):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [x] @cramertj
> * [x] @joshtriplett
> * [x] @nikomatsakis
> * [x] @pnkfelix
> * [ ] @scottmcm
>
> Concerns:
>
> * need-consistency-rvalue-temporary-rules-between-let-and-let-else (https://github.com/rust-lang/rust/pull/93628#issuecomment-1055738523)
> * ~~not-while-rustfmt-breaks-on-it~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1032936704
> * ~~semicolon~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1059799661
> * ~~stabilization-report~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1033846359
> * ~~summarize-concerns~~ resolved by https://github.com/rust-lang/rust/pull/93628#issuecomment-1056785904
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/93628#issuecomment-1029383577):
> Shall we stabilize `let else` syntax? We've had many demonstrated uses, including extensively throughout `rust-lang/rust`, we've seen the value of it, and there aren't any known issues with it.
>
> @rfcbot merge

Implementation path we were taking (lowering to THIR) hit a dead end, we decided to try to do it at MIR lowering time, seems to be going better.

### "do not mark interior mutable shared refs as dereferenceable" rust#98017

- **Link:** https://github.com/rust-lang/rust/pull/98017
- [**Tracking Comment**](https://github.com/rust-lang/rust/pull/98017#issuecomment-1163625324):
> Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
>
> * [ ] @cramertj
> * [x] @joshtriplett
> * [ ] @nikomatsakis
> * [ ] @pnkfelix
> * [ ] @scottmcm
>
> No concerns currently listed.
>
> Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
>
> See [this document](https://github.com/rust-lang/rfcbot-rs/blob/master/README.md) for info about what commands tagged team members can give me.
- [**Initiating Comment**](https://github.com/rust-lang/rust/pull/98017#issuecomment-1163625302):
> @rfcbot merge

nikomatsakis: is there a clear proposal here? How will we remember what we've decided?

joshtriplett: I think it's all contained in the edits of the comments, and I think we should decide on the basis of what's written in the PR.

nikomatsakis: OK.

## Active FCPs
### "Tracking issue for `IntoFuture`" rust#67644

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

### "allow unions with mutable references and tuples of allowed types" rust#97995

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

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

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

### "Initiative: `?` traits, `try` blocks, `yeet` exprs, oh my" lang-team#160

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

### "Initiative: Ghost types and blocks" lang-team#161

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

### "Keyword generics" lang-team#162

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "do not mark interior mutable shared refs as dereferenceable" rust#98017

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

Discussed above; please look asynchronously and check boxes or raise objections.

### "Implement pointee metadata unsizing via a JustMetadata\<T> container" rust#97052

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

Niko + Josh are confused.

nikomatsakis: So this permits you to coerce from the metadata from a sized type (e.g., `&u32`) to `&dyn Debug`. I guess it would be good to know why this is desired, it also lets you coerce from vtable of sub- to super-trait.

nikomatsakis and joshtriplett: why would you want to coerce rather than convert?

joshtriplett: wrapper makes sense, having the ability to see .. what the type was from which you took the metadata.

simulacrum: isn't it just an alias for `<T as Pointee>::Metadata`..? I don't see the point.

joshtriplett: Hmm, yes, it's just an alias, good point. Top comment mentions wanting to implement `CoerceUnsized` for a carefully constructed box that is a box of a fat pointer.

nikomatsakis: I don't understand the `SillyBox` example. I expect think the `SillyBox` would just work if you had `ptr::NonNull<T>`...?

nikomatsakis: let's leave some questions and move on.

[left questions](https://github.com/rust-lang/rust/pull/97052#issuecomment-1169345881)

### "Tracking Issue for `#[instruction_set]` attribute (RFC 2867)" rust#74727

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

pnkfelix is liaison and we wanted to ask him to stabilize, leave it nominated.

### "TypeId: use a (v0) mangled type to remain sound in the face of hash collisions." rust#95845

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

*general discussion*

Alternatives seems to be:

* Include the full symbol pointer + hash (128 bits)
* Equality compariosn may require string comparison (if we fail to coallesce strings across the binaries)
* Plus the binary is bigger (measurement?)
* Symbols can be long, sometimes multi-KB, in some projects that could matter
* Hash the symbol name with a cryptographic hash, extracting 128 bits at random
* Not a perfect guarantee, but as strong as the hash, which is a big deal
* Could also do 256 bit value if that's the concern
* Ralf covers the [impact on formal verification here](https://github.com/rust-lang/rust/pull/95845#issuecomment-11303259290),TL;DR is that you can write the proof "assuming these are unique"

simulacrum: Is this a lang question? It's kind of indistinguishable?

joshtriplett: Lang-ish, it's a question of what we consider to be sound/unsound etc. Are we willing to say that we're not sound if someone finds a collision in a cryptographic hash?

## Nominated RFCs, PRs and issues NOT discussed this meeting

### "ptr::copy and ptr::swap are doing untyped copies" rust#97712

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