Triage meeting 2021-11-02

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