2021-11-02.md

title	tags
Triage meeting 2021-11-02	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

Pending lang team project proposals

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

Link: #96

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

"Deprecate target_vendor " lang-team#102

Link: #102

"Async fundamentals initiative" lang-team#116

Link: #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: #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: #121

• Plan: pnkfelix as the liaison

"Enum Variant Types" lang-team#122

Link: #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: #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: #62

• ~Ready to merge

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

Link: #76

• ~Ready to merge

"consensus decision making" lang-team#113

Link: #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: rust-lang/rfcs#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: rust-lang/rust#73255

• not discussed, still async stuff happening

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

Link: rust-lang/rust#84223

• currently blocked on libs

"stabilize format args capture" rust#90473

Link: rust-lang/rust#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: rust-lang/rfcs#2972

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

Link: rust-lang/rust#87479

"Stabilize const_raw_ptr_deref for *const T" rust#89551

Link: rust-lang/rust#89551

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

Link: #96

P-critical issues

None.

Nominated RFCs, PRs and issues

None.