---
title: Triage meeting 2021-07-06
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-07-06

## Attendance

* Team members: nikomatsakis, joshtriplett, Felix, Scott
* Others: simulacrum

## Meeting roles

* Action item scribe: simulacrum
* Note-taker:

## Scheduled meetings

* Planning meeting (July) 2021-07-07 (tomorrow!)
* Open threads on Zulip collecting status into tracking issues
* Please open issues regarding any meetings for July

## Action item review

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

## Pending lang team project proposals

### "Discontinue meeting recordings" lang-team#100

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

* Continued discussion on thread regarding recording as a way to enable remote participation
* Haven't found a satisfying middle ground yet; we will discontinue meeting recordings, but we may make future changes as well

### "Deprecate target_vendor" lang-team#102

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

* Active discussion on [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/243200-t-lang.2Fmajor-changes/topic/Deprecate.20target_vendor.20.20lang-team.23102)
* Middle field has been "vestigial" for decades, according to maintainer of autoconf who commented on internals
* Originated because everybody just called their OS "unix" for a while
* Became vestigial when variants of unix acquired their own names (e.g., solaris)
* Rust has no active distinctions per vendor
* For the few cases today where there *is* a target vendor distinction
* e.g. `x86-64-unknown-windows-{msvc,gnu}` etc
* the distinction here is *really* the ABI, but it's currently using vendor field (overloaded)
* Proposal:
* Expose this information as ABI (or family) and deprecate use of vendor
* Gives us a more meaningful config option, since we don't have anything that has the same target w/ distinct vendors
* Has arisen many times and likely to affect future targets
* No rush to deprecate, but good to stem the bleeding
* pnkfelix: What do you suggest people write for that vestigial component?
* josh: I originally proposed we just drop that field, like wasm32-wasi
* autoconf folks suggested that if we do that, it may be more difficult for autoconf to process Rust target names
* not clear how important this is
* may make sense to include "unknown" for compatibility reasons
* ultimately an orthogonal concern, don't care so much what the target name winds up being, so long as the field does not have a meaningful value
* josh: been ratcheting the proposal back to make progress on the deprecation, the rest is less important
* nikomatsakis: per our new process, this needs a liaison/owner?
* josh: not much work, probably still worth having a project. I can own it, but need a liaison.

## Proposed FCPs

**Check your boxes!**

### "Add `expr202x` macro pattern" rust#84364

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

* FCP to close -- in favor of discussion on https://github.com/rust-lang/rust/issues/86730 to get a more complete picture.
* The grammar for Rust has various nonterminals for things like "expr" but that meaning has diverged in the context of macro matcher
* so this is an effort to bring those in sync over an edition
* the only precedent we have to refer to is what we did for patterns, where we added `pat_param` to keep the old meaning
* This is not deciding what to do, just recognizing we needed more info to proceed
* Ongoing conversation on whether to use a new name over an edition
* may affect other things beyond expressions, as the parser for macro specifies have generally diverged
* Niko: tempting to suggest we go back to the older form of future compat here
* eagerly consume tokens until a defined separator is found
* parse those as an expression and give a hard error if there are "extra" tokens
* would have to be tied to an edition boundary, but we'd never have to make changes again
* Josh: Design meeting?
* pnkfelix: I might be willing to drive that, I'd like to get a bit more into macros
* Josh: biggest input we would need for that design meeting, I think, would be the impact
* If we went with Niko's route, for example, what would be the impact? How much would break and how easily could we migrate?
* Having some data or work on that would help avoid us going too far down a speculative road.
* Action item: pnkfelix to draft meeting proposal

### "Stabilize `const_fn_transmute`, `const_fn_union`" rust#85769

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

* FCP merge
* checkboxes: https://github.com/rust-lang/rust/pull/85769#issuecomment-873168242
* stabilization report: https://github.com/rust-lang/rust/pull/85769#issuecomment-854363720
* No comments

## Active FCPs

### "`#[derive(Default)]` on enums with a `#[default]` attribute" rfcs#3107

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

* FCP closes in 3 days -- any comments/concerns?

### "RFC: let-else statements" rfcs#3137

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

* Scott: let-else has been having a lot of Zulip conversation, summary?
* Specific areas of comment:
* people poking at the syntax, wanting an earlier 'introducer'
* `guard let`, `let if`, etc
* the owner is not particularly excited about having a variant here
* joshtriplett: I personally think there's a strong consensus towards "just add else"
* the fact that it's a refutable pattern is a clue
* scottmcm: I don't think a refutable pattern is really an introducer, not obvious
* nikomatsakis: I feel like for syntax, the best way is to log the concern, implement, and see how we feel when using it in practice
* joshtriplett: Fishrock123 has been doing a good job logging concerns so that we know the conditions on which to evaluate things
* scottmcm: this would be a fun place to use `k#` to let folks experiment
* pnkfelix: one point is whether this affects our ability to produce good diagnostics in response to small mistakes
* not necessarily an objection, but something to evaluate before stabilization
* nikomatsakis: I think capturing the concerns raised by these -- what to evaluate in practice -- would be really useful
* e.g., introducer seems oriented at this
* interaction with future features
* if-let chains, proposal allowing multiple else's
* introducers help here too
* not a concern about the specific issue so much as forwards compatibility
* the RFC's proposal is preventing things that push us down those paths
* so e.g. you can't do `if let Some(x) = foo else { diverge } { ... }` (nikomatsakis: MY EYES)
* scottmcm: I just have this feeling of "we've had to prohibit enough corner cases that it makes me worried", even though no particular item seems especially large
* joshtriplett: there are lots of interactions, has that "this touches everything" property
* joshtriplett: my feeling is that most of the "special cases" are temporary, apart from "no else on the let inside an if"
* "else on the let inside an if" is prohibited for readability
* nikomatsakis: strong agree. I don't even see that "let" as the same sort of let. As a rule of thumb, I think any place that has `} {` adjacent to one another is "nope, don't do that"
* joshtriplett: `if let pat = StructVariant { ... } {}`
* nikomatsakis: We currently prohibit that for parsing reasons, or at least similar such cases.
* scottmcm: while conditions too
* joshtriplett: are any of these *blockers for the RFC* versus concerns to consider when implementing and evaluating?
* consensus: no, but we should pay attention to scott's point about the "weight" of the various interactions
* We should pay attention to that signal in the future, as well; "weight of small issues" can be a large issue sometimes.
* scottmcm: these issues are currently logged as *alternatives* but not as *unresolved questions*
* joshtriplett: I'll take the action item to talk to Fishrock123 and ensure those things are captured under unresolved questions
* nikomatsakis: not the specific alternatives but the concerns that motivated them
* pnkfelix: are there any interactions with "ref patterns" to be aware of?
* joshtriplett: none in particular.
* scottmcm: equivalent to desugaring into the match.
* pnkfelix: may something with temporary lifetimes?
* joshtriplett: yes, that's a good call; let's capture it in a test case to make sure it works as expected

// something like this, but verify that the match fails to compile
fn foo() -> Option<u32> { Some(22) }
let Some(ref x) = &foo() else {
  panic!();  
};
println!("{}", x);

### "Stabilize "RangeFrom" patterns in 1.55" rust#83918

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

### "Stabilize bindings_after_at" rust#85305

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

### "Discontinue meeting recordings" lang-team#100

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

### "Deprecate target_vendor" lang-team#102

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

## P-critical issues

* None for lang team

## Nominated RFCs, PRs and issues

### "Stabilize "RangeFrom" patterns in 1.55" rust#83918

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

Previous discussion:

> * In FCP for partial stabilization
> * Excludes patterns from slices:
> * we've said in the past we would be ok to stabilize, but if PR author wants to hold back, seems ok

* FCP has completed, so not really T-lang, needs a reviewer
* Action item to flip the labels and ping t-compiler or just review (nikomatsakis)

### "Check for union field accesses in THIR unsafeck" rust#85263

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

* Action item: nikomatsakis to review

### "Fix how allow/warn/deny/forbid `warnings` is handled" rust#85298

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

### "Allow limited transmuting between types involving type parameters" rust#86281

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

### "Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable" rust#86492

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

* Don't have a clear story on when symbols are available
* Currently tied to `#[no_mangle]`, which makes things always available even if they are unused
* Unlike the `#[used]` attribute (perhaps surprisingly)
* This PR notes that `#[no_mangle]` has no effect on associated functions today:

struct AssocFn;

impl AssocFn {
    #[no_mangle]
    fn foo() {}
}

* Current behavior:
* If `foo` is not used, it is stripped from the binary
* Not sure what symbol name would be used if it were used
* petrochenkov thought [perhaps it should be an error](https://github.com/rust-lang/rust/pull/86492)
* No evidence of whether this is used in the wild or not
* joshtriplett: Maybe there should be ways of exporting associated functions, but not sure this is it
* nikomatsakis: doesn't seem to add *expressiveness*, since you could put the `#[no_mangle]` fn inside
* mark: avoids the "shim function"
* nikomatsakis: yes.
* nikomatsakis: we do allow you to specify ABIs...
* just changes the symbol name, which is not *in general* the name users use to refer to it from programs
* joshtriplett: you're suggesting that `#[no_mangle]` just causes `foo` to have the symbol name `foo` here, thus giving a linker error if you have two associated functions?
* nikomatsakis: yes, that's what I assumed it would do
* joshtriplett: I'd like to know what they're trying to do; no mangle conflates "I want this exported" from "I want the symbol name". So...what are they wanting?
* nikomatsakis: note that if you have the same function in two distinct modules, and you `#[no_mangle]` them, you are going to get conflicts; we already discard modifiers iow
* nikomatsakis: seems reasonable to request a use case

impl readlink {
    fn get(&self) -> unsafe extern fn (path: *const c_char, buf: *mut c_char, bufsiz: size_t) -> ssize_t  {
       ...
    }

    #[no_mangle]
    pub unsafe extern "C" fn readlink(path: *const c_char, buf: *mut c_char, bufsiz: size_t) -> ssize_t {
        ...
    }
}

* nikomatsakis: to me the use case is the same as any other `#[no_mangle]` -- I have some Rust code I want called from C, but the natural place for it to live in Rust is as an associated function.
* nikomatsakis: I'm vaguely in favor of adding this, but if somebody wanted to gather data on whether it's used in the wild, I would be interested.

### "Fix autoborrowing when coercing to a mutable raw pointer" rust#86647

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

* Anybody have context? Nope!
* Requires someone to prepare an update
* joshtriplett: Noticing that this is phrased as a compiler change, but there isn't a description in terms of the language semantics.
* Would be nice to have a higher-level update.
* nikomatsakis: this is an example of the kind of case where I'd like to be able to push back and say "can this be formulated as an actual question to be answered"?
* Right now we have to dig through the thread
* It might be hard for the OP to formulate the question precisely of course
* joshtriplett: Yes, a question seems required, but there might also be "can you have somebody dive in and formulate the writeup" -- but that would require someone sufficiently familiar with both lang/compiler details
* pnkfelix: from looking at the issue, I have my guesses as to why we might say this is not what the language wants
* pnkfelix: is it reasonable to expect people to follow a link?
* I'd prefer to have the question front and center.
* simulacrum: the issue doesn't seem to have a detailed write-up either
* nikomatsakis: I think that if the writeup says "there is a write-up here" that would be ok, but in this case we'd have to skim the thread, and also the issue doesn't have much of a write-up
* more like: it'd be ok for a single person to follow links, but not us to do it in real time in this meeting
* nikomatsakis: scottmcm, do you want to do followup?
* PRESSURE IS ON
* scottmcm, reluctantly: ok
*

* This issue, as far as scottmcm can tell: Should `something_that_is_a_value_not_a_reference as *mut T` go through `DerefMut`? It doesn't today.