---
# System prepended metadata

title: Triage meeting 2021-11-02
tags: [triage-meeting]

---

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

# T-lang meeting agenda

* Meeting date: 2021-11-02

## Attendance

* Team members: nikomatsakis, joshtriplett, scottmcm
* Others: simulacrum

## Meeting roles

* Action item scribe:
* Note-taker:

## Scheduled meetings

- Planning meeting tomorrow!
    - We were supposed to prep updates but didn't, how can we do better here?
    - Posting reminders would help
    - Create and publish a template
    - Can we call out "places where people would like feedback"
    - Would be good to have a bot that pings people and groups as well
- Put out a call for design meeting proposals
    - Status updates as a design meeting
    - Possible topics: async dtor
    - Named fn types might be worth it
    - Josh and Niko have been talking about "double dereference" (making `&&T` be the same type as `&T`); would make autoref less concerning
        - probably not at the design meeting stage yet

## Announcements or custom items

* Josh has been going through "implemented but not stabilized"
    * Would be great to have a list of "everything open"
    * Kind of a "backlog bonanza" item
    * Sometimes it's just triaging "why is this tracking issue blocked"
        * unfixed or unresolved design questions
        * not implemented
        * needs to bake and garner usage/feedback
    * Maybe we should start a backlog bonanza effort with that as a goal?
        * "all tracking issues categorized"

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

* Plan: nikomatsakis as the liaison, spastorino as owner
* Already partly implemented, need to make the repo

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

* Plan: nikomatsakis or cramertj as liaison? Need to sync up here
* [cramertj] I'm happy to help-- sync on zulip later? (+1)

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

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

* Hasn't been discussed much owing to lack of quorum
* General idea:
    * a way to declare an extern static where the *declaration* is unsafe, rather than the usage
* Josh: I think fair bit of thought would need to go into semantics. Would need to discuss with Ralf on what the requirements would have to be.
* nikomatsakis: I saw Ralf left some comments.
* scottmcm: I was a bit confused, what's special for statics here? We've had the same conversation about extern functions?
* nikomatsakis: Why not both.gif?
* scottmcm: In some ways the fn case seems more normal to me...?
* joshtriplett: I'd be ok with extern fn too. Statics do seem a bit different than functions (you can read them) so maybe worth thinking about them separately.
* nikomatsakis: I'm in favor of the idea, but didn't want to serve as liaison because overloaded.
* josh: "just a metter of getting the details right"

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

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

* Plan: pnkfelix as the liaison

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

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

* josh: these have been discussed for years. Can we have a type for a "subset of an enum"?
* nikomatsakis: As above, not opposed to the idea, but I didn't feel I had the bandwidth to think about this.
* josh: I like that it's a relatively narrow proposal. Not supporting arbitrary subsets, just each variant is its own type. Could extend this to have multiple variants.
* nikomatsakis: I'm concerned that this change will have a lot of repercussions (e.g., we might want to make changes over an edition, etc). I think it will require an engaged liaison and iteration to get it working in practice. I'm nervous about opening that door without somebody dedicated.
* scottmcm: subtyping, coercions...
* josh: ...implementing traits on variant types...
* josh: ...can definitely foresee a future soundness hole from some weird corner case.
* nikomatsakis: my fear is specifically that this will be the next never type unless we have somebody dedicated to it.
* josh: not clear if the right answer is to have somebody implement it?
* nikomatsakis: it sounds like we are leaning towards declining this proposal. "not never, but not now."
* scottmcm: what would it take to have confidence in this?
    * do we want somebody to say "here is what I've identified as the tricky bits, this is my plan, I'd like to do it as a prototype"? Or....?
* josh: I'd like to see that with, ideally, some flavor of "I'm deeply familiar with type systems".
* scottmcm: sounds like it's also 'the type inference consequences of this are complicated enough that we'd be unwilling to take it without chalk'
* nikomatsakis: I've been trying not to say chalk, but I am wanting to spend the next year focused on bringing our type system impl "under control" and I would be happier to look into this yesterday. 
* nikomatsakis: I think what I would want is roughly what scott said but *also* somebody from lang team who has the knowledge pre-req and is wanting to be involved.
* josh: I could see this being closed with "we'd like to see this, but we're not ready to make this change yet".
* nikomatsakis: I'd be up to write the comment and move to close.
* scottmcm: I feel like this is going to want a new subtype, and that's scary, because we have very few of those.
* nikomatsakis: also they interact poorly with the trait system (specialization).

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

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

* Josh: Let's not discuss at length, I can give an intro. People can read async, there's a good Zulip thread, too.
    * Short version: A long time back, we had an RFC that said `usize` and `isize` are not `size_t` but rather "pointer_t". Usually the same but there are rare platforms where they are not.
    * Two concrete cases: ARM has a pointer tagging mechanism ("cheri") with 128-bit pointers, even though addr space is 64-bit. Pointers have a "security tag" that prohibits you from forging a valid pointer. So `size_t` is 64-bit but `uintptr_t` is 128 bit.
    * Other case (obscure) is "super nintendo" processor
        * Had 32-bit pointers with 16-bit `size_t`
    * Tradeoff:
        * a lot of code assumes `usize` is big enough to hold a pointer
        * a lot of code assumes `usize` is `size_t` for FFI purposes
    * Can't satisfy both of those simultaneously, so...
        * have to decide that we won't support those platforms
        * or that `usize` is truly `uintptr_t` (like the RFC said...)
        * or that `usize` is truly `usize_t` (...a bit breaking)
* Niko: This feels like it has a "portability lint" flavor, it may be useful to write libraries that do assume that `usize` and `size_t` are the same.
* Josh: +1 for the portability lint, if we consider doing this at all.
* Niko: Feels like we probably want "usize is `uintptr_t` as we said, but most code is allowed to assume those are the same, and there's a way to opt out"...?
* Scott: the other part is that all the library methods that take `usize` are a bit awkward if that's not *actually* what you wanted (e.g., indexing).
* Niko: Fair. Mostly I think that most people *will* treat them the same, whatever we say =)
* Josh: what would go wrong if we treated ARM CHERI as though `size_t` were 128-bit?
    * Josh: incompatible with C, obviously
    * How inefficient would it be, though?
* Scott: people could use `u64` instead of `usize`....
* Niko: maybe there wants to be a way for libraries to be like "I'm C integer type compatible" and hence opt-in to `ptrdiff_t` vs `usize_t` and so forth.

## PRs on the lang-team repo
### "Initial draft of copy ergonomics design note" lang-team#62

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

* ~Ready to merge

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

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

* ~Ready to merge

### "consensus decision making" lang-team#113

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

* Felix gave feedback, Josh responded and incorporated
* Ready for another round of review 
* Felix can merge when ready

## RFCs waiting to be merged

None.




## Proposed FCPs

**Check your boxes!**

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

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

* MVP for async fn in traits
* Targeting "static dispatch" - traits that use async fn with this proposal aren't `dyn` safe
* Desugars to use an associated type that implements `Future`
* Forward-compatible - could work towards dyn safe in the future
* Interacts with named function types
* This would let us start implementing `AsyncRead`/`AsyncWrite`/etc
* Potential future workaround: build a struct using "the erased-serde trick"

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

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

* not discussed, still async stuff happening

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

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

* currently blocked on libs

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

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

* `println!("{foo})"` -- huzzah!
* niko: Is this in the Rust reference?
* josh: No, reference doesn't cover the format syntax at all, it's kind of a library thing, technically.
    * It's documented in the `format_args!` documentation.
* scottmcm: if we had a way to say "look up this variable using the hygiene here", this would be entirely 'proc-macro-able', right?
* josh: yes, I believe so, and there was some comments about that in the expand-expr thread.
* nikomatsakis: would be nice to have a short blog post once this hits stable... "yay for editions! now we have this nice feature!"
    * josh: yes, and the history of what we had to do with `panic`
* scott: this only accepts a single token, right? you can't do `{foo.bar()}`? 
* josh: correct. a better error message was proposed but regardless we give a syntax error.
* scott: Great. I was going to ask how it handled escaping and tokenization but I don't have to now.

## Active FCPs
### "Constrained Naked Functions" rfcs#2972

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

### "GATs: Decide whether to have defaults for `where Self: 'a`" rust#87479

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

### "Stabilize `const_raw_ptr_deref` for `*const T`" rust#89551

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

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



