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

# T-lang meeting agenda

* Meeting date: 2021-11-09

## Attendance

* Team members: nikomatsakis, cramertj
* Others: lokathor

## Meeting roles

* Action item scribe:
* Note-taker: nikomatsakis

## Scheduled meetings

* **Need to create calendar invites!** D'oh. 🤦
* Nov 10: Backlog bonanza - tracking issue triage
* Nov 17: Impl trait overview (inference algorithm, named fn types)
* Nov 24 (day before thanksgiving): Never allow unwinding from drop impls (https://github.com/rust-lang/lang-team/issues/97)

## 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
### "negative impls integrated into coherence" lang-team#96

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

* Repo is created, Niko started working on write-ups, need to close issue

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

* lokathor: There seems to some agreement that it's a good idea--- should I just go ahead with an RFC?
* nikomatsakis: I would want to see a liaison, seems like maybe a Josh thing.
* joshtriplett: I could this but in general the list of liaisons needs rebalancing.
* Once upon a time we had a discussion about having a limit of the number of things one can liase, and it seems like a good idea.
* nikomatsakis: let's discuss on Zulip in t-lang but I think we can have you as backup.
* nikomatsakis: do you think there would be supporting documents or does an RFC suffice?
* lokathor: probably just an RFC
* nikomatsakis: agreed.

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

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

* nikomatsakis: Do we have a repo here?

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

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

* Niko started writing a comment here, will finish up

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

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

* Bunch of add'l discussion on zulip, internals threads
* Still no firm conclusion but seems to be leaning in direction of "not worth it, would break too many things"
* nikomatsakis: Seems like it's not going to get any *harder*, we're going to be building up a sub-ecosystem that tries to be portable across this, could do it in the future when there's more demand
* joshtriplett: would be a great case for the portability lint ("the fabled portability lint" -ed.)
* joshtriplett: fabled, yes, it's becoming one of those "all things would be awesome with this", like GATs and const generics
* nikomatsakis: which may argue for making it a priority
* joshtriplett: what those are doing for writing code and building abstractions, the lint would do for language evolution
* would give us the option to say "here are things that everyone has to care about" and here are things "people who want to care have to care about"
* nikomatsakis: I think for portability lint to really work it'd want to be encoded in cargo metadata
* joshtriplett: kind of like future incompat?
* nikomatsakis: it'd be useful if you could go to crates.io and say "I want to limit myself to the no-std ecosystem"
* joshtriplett: or, conversely, I only care about 64-bit platforms, only care about linux, etc and am willing to include traits that are not widely portable
* should absolutely work on cargo but not a blocker
* lokathor: what needs to be supported...?
* limiting certain casts, transmutes?
* just need to block a few operations and see what keeps building, right?
* josh: effectively, yes. There are a few more. There are some things the portability lint would make really straightforward, like trying to limit as casts. If you have to call `.truncate_pointer` or something instead of `as`, that would be more declarative, and long term we probably want portability lint to be able to say "it's ok to assume pointers are either 32 or 64 but you have to opt-in for other platforms".
* lokathor: kind of like cargo features, but for lang?
* joshtriplett: for the target, but yes. I think that another big one will be making it possible to use `.into()` on some platforms but not others.
* cramertj: do you mean any use of a `usize: Into<u64>`?
* joshtriplett: I imagine the trait impls would exist or not exist depending on your portability settings.
* nikomatsakis: or a warning, right? the impl exists, but your use of it yields a warning.
* scottmcm: there are also some unsound things on 16-bit platforms because of "trusted len" on `Range<usize>` or .. something?
* *general collective sigh of despair and/or longing*
* Ah, found it: `RangeInclusive<u16>: ExactSizeIterator` is incorrect on 16-bit, since `(0..=u16::MAX).len()` wraps. So maybe not exactly soundness.
* cramertj: sounds like a design meeting topic!

## PRs on the lang-team repo

Consensus based decision making was merged :tada: and joshtriplett is talking to spastorino about potentially implementing it

### "Initial draft of copy ergonomics design note" lang-team#62

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

### "Add draft of variadic notes" lang-team#76

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

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

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

FCP has completed. Somebody needs to do the merging.

* nikomatsakis: Not it. :touch-nose:
* joshtriplett: rolls 1d5-- cramertj?
* cramertj: I can do that!
* nikomatsakis: feels like a "subpart" of the inline assembly initiative to me?
* joshtriplett: definitely related, just an RFC, there was an implementation.
* nikomatsakis: that all seems fine but I think it should just be a "subpart" of the inline asm.
* joshtriplett: owner is Nathaniel McCallum.
cramertj: this is only valuable with inline assembly, right?
* joshtriplett: right, this would come after that.
lokathor: Amanieu wrote stabilization report for inline assembly was this morning by Amanieu ([issue](https://github.com/rust-lang/rust/issues/72016#issuecomment-964186287))
* joshtriplett: I'm going to kick off FCP RIGHT NOW. *oddly loud typing follows*
* (snrk)
* joshtriplett: what teams make sense?
* nikomatsakis/pnkfelix: makes sense to include compiler team since it is strongly coupled to the backend and we want "sign off" on the maintenance
* lokathor: docs don't match the current LLVM behavior in one area. I'd prefer to match LLVM's behavior, Amanieu disagrees but LLVM can't support that.
* joshtriplett: that's an argument for matching LLVM, but also potentially an argument for not stabilizing yet.
* pnkfelix: is this part of the stabilization report?
* lokathor: no, doesn't appear to be.
* lokathor: on thumb1, one of the register classes, the docs say "all registers" are usable, but it's actually only half. Almost nobody does thumb1 programmer, except me.
* joshtriplett: it sounds like you're saying this is a doc bug, but behavior is what you think it should do
* scottmcm: would it be back compat to allow *more* registers in the future?
* lokathor: the thing is that in thumb1 registers above r7 aren't usable for a lot of instructions, so if it allocates you (say) r8 and you happen to use it with some instruction, you're going to get an error.
* nikomatsakis: sounds like it's *not* backwards compatible, you're supposed to be encoding the range of registers for the architecture you're using.
* lokathor: right, amanieu's concern was that it was one extra thing to think about in case you *might* be targeting thumb1. But most chips are not using thumb1 anymore, which dates back to 2010 or something.
* josh: do you have the bandwidth to send a PR to the docs?
* lokathor: yes. to the unstable book?
* josh: yes, they should eventually move to the rust reference but for now the unstable book is the place. I think you should lay out the pro/con arguments in the PR thread so we can make the decision there ia fcp merge.
* cramertj: the thing we're talking about disallowing is stuff that wouldn't work anyway, right?
* pnkfelix/lokathor: some instructions could be used...e.g. add, mov
* nikomatsakis: the backwards incompat scenario is that you have code that only works for R1-7 but uses the "general" register class (or whatever it's called) and is thus relying on R1-7
* lokathor: right, the path forward would be to add a class for the higher registers (R8+)
* pnkfelix: where are the docs?
* lokathor: I think it's in LLVM's docs...a lot of our docs point to LLVM right now. ([llvm docs](https://llvm.org/docs/LangRef.html#supported-constraint-code-list))

## Proposed FCPs

**Check your boxes!**
### "Tracking issue for `#![feature(const_precise_live_drops)]`" rust#73255

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

* nikomatsakis: In the past we requested some docs on the analysis, there is:
* https://github.com/rust-lang/rustc-dev-guide/pull/1240
* I plan to review.

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

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

* nikomatsakis: still blocked on libs, right?
* cramertj: I think the last point was that maybe we wanted different syntax?
* nikomatsakis: I'm not sure it was a consensus point, but some folks did want different syntax.
* cramertj: I was under the impression that was the direction it was going. Somebody pointed out that it was more expansive than what we allow in const blocks today?
* simulacrum: I think that was a bug in the implementation more or less, need an intermediate constant.
* nikomatsakis: it has somewhat of a deeper semantic difference, right? or can you think of it as just a `const` value that is inline?
* simulacrum: I think you can think of it as just a value. It's kind of "just an optimization".
* nikomatsakis: if you can think of it as "just an optimziation", then I'm happy.

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

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

* joshtriplett: saw some activity here
* nikomatsakis: three things got brought up
* rustfmt
* formatting of where clauses on constants
* formatting of where clauses if we were to add `fn foo() = body;` notation (`fn=` notation)
* cramertj: we are talking about all type aliases, right?
* nikomatsakis: I think we would want to use the new where clause notation to get the right behavior, instead of ignoring them. I'm not 100% sure that's the right behavior but I'd like to keep the option.
* cramertj: you think there'd be a big time delay between the time we accept the new syntax for gats vs other type aliases?
* nikomatskais: between the time we stabilize them, specifically.
* josh: isn't there something about type aliases?
* in particular, petrochenkov feels the idea of where going after the `=` is inconsistent
* I find the combination of that to be relevant
* nikomatsakis: did you read my response?
* nikomatsakis: (elaborates on the signature part)
* cramertj: I think there's a difference, because the right hand of the equals feels like an item definition, reads to me like the where clause coming after the definition. If that makes sense.

trait Foo {
    type Bar<T>: Baz
    where Self: 'a;
}

impl Foo for Bar {
    type Bar<T> = BazType
    where Self: 'a;
}

* josh: what about accepting both?
* nikomatsakis: now we have to make a rule for accepting what order they should go on?
* josh: well, we don't *have* to, rustfmt could preserve it
* nikomatsakis: I'm all in favor of giving people the option to make important distinctions, but I don't think this is one
* cramertj: yeah, I don't think I want both, I find the `T: for<'a> Trait` and `for<'a> T: Trait` question
* josh: to go back to the earlier topic and ignore the "we could do both" question...
* I agree with the argument of this will make copy/paste easier
* But I'm also sympathetic to the "inconsistent" case
* I'm wondering to what extent this makes sense from a copy/paste
* nikomatsakis: I personally find it more consistent both aesthetically ("if I squint and ignore the keywords, it looks right") and semantically ("when I think hard about where it should go")
* cramertj: I disagree with a change but I wouldn't block it
* josh: my brain intuitively wants to put the where after, because it makes sense, the type on the RHS is usually short-ish, and the where should be an "afterthought", but at the same time I'm having a hard time justifying that
* I find both petrochenkov's argument and line 184 compelling
* having a hard time wanting to accept what my intuition wants over what feels like language consistency
* nikomatsakis: I think if we added `fn=` syntax, we probably should format it like this. I consider it consistent for the reasons I made the case.

fn foo<T>()
where
    T: Trait
= {
    
}

* joshtriplett: I'm not sure if I'm supportive of this as much as petrochenkov is against it. I may file a concern on this one, not because I know definitely which way I want to go, but because I haven't made up my mind.
* nikomatsakis: that seems like a good thing to do if you are unsure. Just that at some point we will have to make a call.
* cramertj: I don't think I have a concern myself, just a different aesthetic preference, I also think you have much more experience using them than I do.
* nikomatsakis: I think it's a great idea to try and write some code and see how you feel about it. It's not a straightforward call.

## Active FCPs
### "Static async fn in traits" rfcs#3185

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

### "stabilize format args capture" rust#90473

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

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

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

## P-critical issues

None.

## Nominated RFCs, PRs and issues

None.