---
title: Triage meeting 2021-11-16
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-11-16

## Attendance

* Team members: nikomatsakis, pnkfelix
* Others: lokathor, Mara

## Meeting roles

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

## Scheduled meetings

* Impl Trait Overview 2021-11-17
* [document is basically ready](https://hackmd.io/5MakNcwCRDKWnP6UTL58wg)
* Disallow panic in drop 2021-11-24
* Amanieu prepared a document for this already

## Announcements or custom items

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

## Action item review

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

### Attribute for trusted external static annotations

* [rust-lang/lang-team#118](https://github.com/rust-lang/lang-team/issues/118)
* Lokathor made a PR, as discussed last week
* Given `extern static FOO: [u32; 10]` or whatever
* if you declare it correctly, not static mut
* shouldn't need to use unsafe when you access it
* currently you do need to
* Proposal:
* Let's add an attribute on the declaration saying it is trusted
* But:
* Either it's already correct without the attribute
* we don't require it on Rust immutable statics
* Ralf had a concern that there could be some patterns used by C that are no longer expressible
* Counter proposal:
* Make declaring an extern static count as unsafe code
* e.g. `unsafe extern`
* What is unsafe for?
* Mara:
* Lokathor: if there's no amount of check that can make a dangerous thing not dangerous...what do we gain from it?
* nikomatsakis:
* I think we want to be able to say, per item:
* all uses are safe, definition is unsafe
* versus unsafe to USE
* the question is: if uses are unsafe, do we also need to audit definitions?
* answer: maybe yes, because llvm
* in my mind, good case for
* definitions should always be unsafe
* you can declare that uses should be safe
* backwards compat?
* coul
* nikomatsakis's proposal:
* warning for extern block unless declared as unsafe
* to account for LLVM and because, indeed, if these are wrong, code is wrong
* adding an attribute like `#[trusted_extern]`
* can be applied to any sort of extern, makes uses safe
* [Draft RFC](https://hackmd.io/@Lokathor/Sk-RXL_PK)

## Pending lang team project proposals
### "negative impls integrated into coherence" lang-team#96

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

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

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

### "Async fundamentals initiative" lang-team#116

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

### "Attribute for trusted external static declarations" lang-team#118

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

### "Prototype Sync & Async Iterator Items (Minimal generators)" lang-team#121

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

### "Enum Variant Types" lang-team#122

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

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

* Josh seconded it; it's in FCP, unless someone objects, will go to the "experimental" zone (needs an RFC).
* scottmcm pointed out that this forbids future evolution of a type parameter with a default.
* Other concerns:
* Can this lead to user confusion, how can we test that?
* Generics vs associated types are probably confusing
* Without a clear-ish rule, will people be more confused?
*
* You won't know how to name the type
* How important are names?
* For things like `Iterator` and `Future`, decent argument that seeing the names don't help you in reading the code.
* Mara: maybe it should just work for things with exactly one type, and nothing else.
* Mara: can we have rust-analyzer autocomplete this instead, and keep it same for readers?
* Josh: don't want this limited to IDE users
* How confusing will it be between generics and associated types?
* Mark: How do I learn the difference between generics and associated types? Today, perhaps, based on other existing traits
* How important are the names to readers?
* e.g. is this just about *writing* or also reading
* Loka: Standard library code uses all of "Target", "Output", and "Item", for roughly the same concept.
* nikomatsakis: I remember that around the time we were stabilizing things we considered always using `Output` precisely so that we can have a simple default, but we never did it.
* mark: regarding "how important are they", is the *name* important, or is it good enough to know it is an associated type?
* `Iterator<=u32>` or `Iterator -> u32
* Mara: doesn't seem worth it
* mara: I also don't like the extra attribute (e.g., positional) makes me have flashbacks to C++, lots of variations.
* pnkfelix: something I would want investigated: the proposal makes claims about incoming Rust programmers and how they might understand these differences, I think any argument based around this change improving the learning curve, needs substantiation.
* I don't feel conflating things improves learning curves, though "IANAE" (I am not an educator).
* niko: I tend to feel that forcing people to pay attention to things isn't a winner, but hiding them isn't necessarily either.
* mark: my intuition is that, in some future scenarios, the distinction between generics and associated types may become important in new ways, as well.
* pnkfelix to summarize and post on the github and zulip.

## PRs on the lang-team repo

merged!

## RFCs waiting to be merged
### "Constrained Naked Functions" rfcs#2972

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

* nikomatsakis to merge
*
### "Static async fn in traits" rfcs#3185

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

* nikomatsakis to merge

## Proposed FCPs

**Check your boxes!**
### "Tracking Issue for inline assembly (`asm!`)" rust#72016

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

Stabilization report:

* https://github.com/rust-lang/rust/issues/72016#issuecomment-964186287

### "Tracking issue for `#![feature(const_precise_live_drops)]`" rust#73255

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

* bugs were found, canceled FCP for now

### "Tracking Issue for const-initialized thread locals" rust#84223

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

* blocked on libs

### "Change location of where clause on GATs" rust#90076

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

* blocked on concern by josh

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

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

### "Enum Variant Types" lang-team#122

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

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

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues

https://github.com/rust-lang/rust/labels/I-lang-nominated

### Make specifying repr optional for fieldless enums #88203

Example of code that is accepted with this PR (but not before):

enum Enum {
  Unit = 1,
  Tuple() = 2,
  Struct{} = 3,
}

Specifically what's changed is that you don't have to specify a repr. This would be accepted on master if you used an explicit repr type.

Loka: wait no it wouldn't: [even with the repr attribute](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=49cb4ad957f89dd3c84df9550c5f587f) the code above doesn't compile on nightly.

Questions:

* Does `as` work for this enum?
* Hypothesis: no
* If you put a repr on this, though, it is unstable
* Wouldn't we expect this to be "no more stable" than an explicit representation?

### Tracking issue for allowing overlapping implementations for marker trait [#29864](https://github.com/rust-lang/rust/issues/29864)

no idea why this is nominated

probably https://github.com/rust-lang/rust/issues/89515 (after https://github.com/rust-lang/rust/pull/89357#issuecomment-932990251) ?

### Disallow non-c-like but "fieldless" ADTs from being casted to integer if they use arbitrary enum discriminant #89234

Related to what we were just talking about?

#![feature(arbitrary_enum_discriminant)]

#[repr(u8)]
enum Enum {
    Foo = 1,
    Bar(),
    Baz{}
}

fn main() { }

This works, but only on nightly, and the feature + repr are both required. If this issue is just about accidental stabilization, then I think this issue can be closed.

nikomatsakis commented.

### Stabilise feature(const_generics_defaults) #90207

[Stabilization report](https://github.com/rust-lang/rust/pull/90207#issuecomment-958843546)

### Relax priv-in-pub lint on generic bounds and where clauses of trait impls. #90586

* [petrochenkov forwarded this](https://github.com/rust-lang/rust/pull/90586#issuecomment-968540529)
*