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

# T-lang meeting agenda

* Meeting date: 2021-11-23

## Attendance

* Team members: nikomatsakis, Taylor, Felix, scottmcm, joshtriplett
* Others: Lokathor, simulacrum

## Meeting roles

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

Niko: Josh, How do you feel about running the meeting.
josh: Good! How do you about taking notes?
Niko: I **love** taking notes!

## Scheduled meetings

- **Tomorrow:** "Never allow unwinding from Drop impls" [lang-team#97](https://github.com/rust-lang/lang-team/issues/97)
- nikomatsakis: can you reach out to amanieu to make sure he's all set?
- **Next week:** Planning meeting!
- pnkfelix will be absent

## Announcements or custom items

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

* nikomatsakis: after the design meeting last week, went back to drawing board, have a simpler and different design. Had a stakeholder meeting where we laid out the "async fn in trait MVP plan" and got feedback.
* Lokathor: while programming, I noticed that a const generic value, if an expression, has to have braces. But an array size is warned *against* having braces. Should this maybe be allow by default?
* Josh: Specifically, `[T; {size expression}]`?
* cramertj: it is unambig, right?
* lokathor: I had the braces because I had the expression twice, and in one context I needed `<{X*2+3}>` but in the array context of `[T; {X*2+3}]` the `{}` was against.
* cramertj: we should accept either, but it *is* unnecessary.
* nikomatsakis: in other words, you think the lint is appropriate?
* cramertj: if we think that lints against typing extra things are appropriate, e.g., unnecessary parens
* if we want to have a warn-by-default lint against unnecessary braces, then that is a position where they are unnecessary
* nikomatsakis: I think that lint is not correlated with having bugs-- I tend to think that this lint should be in clippy
* cramertj: right, that's why I phrased it that way. I'm not sure if it *should* warn, but I think it should be consistent.
* joshtriplett: was this in a macro? in that context it should definitely not warn
* Lokathor: [Zulip Thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang)
* pnkfelix: can we all agree though that a change in isolation is not appropriate, and that if we are going to make a change, it should be the broader philosophy?
* scottmcm: yes-ish -- the opposite side of the argument is that there are other places where parents are not strictly necessary, e.g., `(a*b)/c`, where many people consider them helpful.
* joshtriplett: I would want to have warnings on if conditions, for example, because they really help people understand the normal Rust style. But in this case it feels 'less absolutely critical' that we warn.
* nikomatsakis: I'm not sure if I consider using braces on `()` *critical*, but I can see that there's going to be some confusion about where you need `{}`. It might be nice if we just accept them everywhere.
* scottmcm: Personally I would like `Array<>`.
* ... some chatter ensues ...
* cramertj + nikomatsakis: should we move on?\
* cramertj: I think the original question was "what are the next steps", and I think that making an issue is the next step.
* scottmcm: isn't that Zulip thread?
* nikomatsakis: procedurally you create a PR and we fcp it. But it's clear there isn't a consensus on whether to accept it.
* joshtriplett: a gh issue sticks around after conversations dies out, for better or worse.

## Action item review

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

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

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

* Short version: possible to write `Iterator<Foo>` instead of `Iterator<Item = Foo>`
* pnkfelix has an action item to summarize the conversation from last week
* joshtriplett: did that cover the origin of this, e.g., generator syntax?
* Lokathor: I remember that we talked about iterator/future as primary driver
* joshtriplett: yes but the thought was that this might make the difference as to whether generators return `Foo` or `impl Iterator<Item = Foo>`. This might make the difference that makes it feel brief enough.
* nikomatsakis: I would consider consistency with async fn more important, but let's take it to zulip.

## PRs on the lang-team repo

None.

## RFCs waiting to be merged
### "Static async fn in traits" rfcs#3185

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

* Action item: nikomatsakis

## Proposed FCPs

**Check your boxes!**
### "Change location of where clause on GATs" rust#90076

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

## Active FCPs
### "Tracking Issue for inline assembly (`asm!`)" rust#72016

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

* joshtriplett: Stabilizing inline assembly... :tada:
* lokathor: Unfortunately without consts, at least initially.
* joshtriplett: True, but we can do that incrementally.
* nikomatsakis: last time we were talking about something to do with thumb assembly?
* lokathor: I put in the doc PR and it was merged, so I believe their thought was that we can just add an add'l register class if we ever need it.

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

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

* "in fcp"
* landed original design with a [tweaked expansion](https://github.com/rust-lang/rust/pull/90774/) that uses an actual `const`
* Some discussion about what happens if the type needs `Drop`.

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

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

* niko just needs to merge and create repo, it's like 75% done
* but spastorino has been working on the impl and it's going well

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

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

* nikomatsakis: My recollection is that we had a concern around "learnability" -- will this make the role of GATs etc more confusing? I don't necessarily see this as a blocker but as something to be considered before we go too much further with stabilization and what not.
* joshtriplett: per our new discussion about procedure, this seems like a reversible decision, I was the one who seconded it, but people do have legit concerns, can we distinguish between "this is something that people want to block further experimentation" or "people have concerns that should be kept in mind during experimentation".
* nikomatsakis: I consider it the latter.
* mark: I would add that I think it would be useful for, whoever is driving the investigation, to assess whether they think they'll be able to respond to the concerns. It would be a blocker, perhaps, if we have no idea how to even approach the question.
* joshtriplett: good point, I think it's important for people to explicitly acknowledge concerns and make a plan for how they'll be addressed.
* scottmcm: I think I'm one of the more skeptical people, but I don't have a problem with experimentation. But I do worry about limbo items.
* joshtriplett: I do not want this to "accidentally create facts on the ground" that create an inertia against evaluating.
* nikomatsakis: we might consider -- not at this second -- how to 'garbage collect' experimentation when it is not making progress in answering the questions (e.g., if implementor goes away).
* joshtriplett: yes, we should ack that the role of experimentation is to gather concerns.
* joshtriplett: in the past, we've had features marked as experimental, this is perhaps not as dangerous as one of those. Procedurally, do we want a flag for which there are open concerns?
* nikomatsakis: in the initiative process (mentioned below) we say we should use that flag for anything that hasn't been RFCed, so perhaps we should use it.
> Code can be landed in this phase, but the feature gate is marked as "experimental" and its associated page in the Unstable Book also incudes a disclaimer that the content has not been RFC'd.
> https://lang-team.rust-lang.org/initiatives/process.html
* scottmcm: I had interpreted that "incomplete" flag as "don't report bugs" which feels distinct from "there are lang concerns about it".
* nikomatsakis: I agree it's not a perfect fit, it'd be nice to add another "twist".
* Lokathor: I think the public perception of incomplete features is "expect the compiler to ICE".
* joshtriplett: whereas here, ICEs ought to be reported.
* scottmcm: it's possible that this should be done in the unstable book.
* nikomatsakis: action item to file an issue requesting a second flag and tag it as E-easy and E-mentor and I think we can get someone to do it.
* pnkfelix: we should perhaps move on but this feels related to nrc's suggestion of removing `yield`.
* joshtriplett: this design-incomplete tag might apply there, and might help make sure people don't think it's near-final syntax
* nikomatsakis: something that says "outstanding design concerns" and points people at issues seems like a good fit for that, it might say "not going to land ever"

## P-critical issues

None.

## Nominated RFCs, PRs and issues
### "Tracking issue for allowing overlapping implementations for marker trait" rust#29864

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

* scottmcm: Bad scott, I should've written a comment. Some thoughts from Ryan about "hey how do we move forward". Any thoughts? Are people relatively happy with `#[marker]`? What do we need to stabilize it? I don't anyone ever answered from Aug 2020.
* pnkfelix: Who are the stakeholders on this thing?
* nikomatsakis: I don't think we have a concrete list of stakeholders, but I've wanted it from time to time. I think there are some soundness concerns with current implementation.
* joshtriplett: should we refer to the chalk team? Do we know if the chalk folks are confident in the soundness of this?
* nikomatsakis: we should ask jack huey, or others, he may remember the soundness concerns.
* but in general chalk can handle this much better.
* scottmcm: we've limited it fairly substantially, e.g. no assoc types?
* nikomatsakis: I think there was an impl bug, but I have to go look.
* Action item to nikomatsakis to copy wg-traits and write a comment
* done!

### "Deprecate crate_type and crate_name nested inside #![cfg_attr]" rust#83744

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

* Implementation needs review.
* Did have a crater run.
* pnkfelix: I think the attributes are useful, so you can have standalone files, but removing the conditional version seems reasonable.
* Lokathor: I think these go way back... I always assume they predated cargo...
* nikomatsakis: I think they go way back.
* joshtriplett: it sounds like nobody objects to this, does someone need to review?
* nikomatsakis: maybe we need an FCP?
* simulacrum: it's just a FCW, so this is reversible
* nikomatskais: ah, nice.
* simulacrum to review

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

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

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

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

* confusion ensues -- niko thinks this is an issue, etc etc
* the question ultimately seems to be which of these variants we want:
* https://github.com/rust-lang/rust/issues/88621 has the three variants
* this PR changes Kind 2 to behave like Kind 3 (`as` is an error)
* scottmcm: you could put non-exhaustive on the variant if you wanted to ensure it is forwards compatible...
* nikomatsakis: ...but note that making Kind 2 into an error is something we could reserve.
* nikomatsakis: I think that making parens to be significant feels consistent with the behavior of `struct Foo;` vs `struct Foo()` and so forth.

This compiles today: <https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=39ed3d3080297dbb59f2f9ee6a652673>

#[repr(u8)]
enum Foo {
    A,
    #[non_exhaustive]
    B,
}

fn main() {
    let _x = Foo::B as u8;
}

* nikomatsakis: I expect the behavior to be that cross-crate, you require `{}`. This feels like an orthogonal question though.
* joshtriplett: do we have consensus amongst people in the meeting to go forward?
* scottmcm: I support that, a bit scared about non-exhaustive, but that's a different problem that doesn't address this PR.
* Filed https://github.com/rust-lang/rust/issues/91161
* pnkfelix: sounds great,
* joshtriplett: [comment posted](https://github.com/rust-lang/rust/pull/89234#issuecomment-977022018)

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

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