---
title: Triage meeting 2022-03-08
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2022-03-08

## Attendance

* Team members: nikomatsakis, Felix, Josh, scottmcm
* Others: Mark, Lokathor, Urgau, Michael, Jane

## Meeting roles

* Action item scribe: Mark
* Note-taker: nikomatsakis

## Scheduled meetings

* Mar 9: Roadmap lang-team#140 (nikomatsakis/joshtriplett to write document)
* Mar 16: Backlog Bonanza!
* Mar 23: RPITIDT lang-team#144 (nikomatsakis/tmandry to write document)
* Mar 30: Lint policy lang-team#132 (pnkfelix to write document)

## Announcements or custom items

* Steps posted for creating tracking issues for project proposals:
* https://lang-team.rust-lang.org/initiatives/process/checklists.html#approve-a-proposal
* see items below

## Action item review

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

## Pending lang team project proposals
### "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

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

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

joshtriplett: there was an extensive amount of Zulip discussion in the last week. Effectively, what do we think the appropriate way to handle this could be in order to support other targets with various properties? Conclusion that we came to on Zulip was that

* we could make an incremental step to agree that `usize` is `size_t` and *some name that CHERI used for the size of a pointer value* `ptraddr_t`, which is non-standard but defines the numeric size of a pointer address (on CHERI, addr space is 64 bit, but ptrs are 128 bit b/c of security tags; on that architecture, `ptraddr_t` is 64-bit, but `uintptr_t` is 128-bit). Conclusion that we roughly came to on Zulip was that we could define `usize` to be `size_t` and `ptraddr_t`, and leave open the question for whether we are willing to make compromises necessary to allow `usize` to *not* be `uintptr_t`.
* That would unblock some things now and we can revisit the portability question.
* Would be a divergence from the original RFC that introduced usize, which defined `usize` to be `uintptr_t`.
* That may just have been a mistake.

nikomatsakis: is the next step here an RFC?

scottmcm: sounds to me like if goal is to declare "this will be the case from now going forward" and "undoing a previous decision" that an RFC sounds appropriate

joshtriplett: I agree. If this hadn't previously been in an RFC, I would've just suggested a PR updating documentation for `usize` and `std::ffi::size_t` and similar. But given that this went through an RFC I think we need at least a minimal RFC.

nikomatsakis: would that RFC say "it's defined as `ptraddr_t`, which on all major architectures is `uintptr_t` etc?"

joshtriplett: I think we would say it's deferred until we add such an architecture. Two reasonable paths:

* we don't support `uintptr_t` and `usize` being different
* or, we do, but on those architectures, `usize` is not `uintptr_t`

scottmcm: what concretely can someone observe right now that cares?

scottmcm: if this is an RFC saying "we're thinking of doing this in the future" does that really need an RFC? FFI type aliases could in theory be u32, u64? That would break some platforms... but the platforms that would break would be the ones that don't have the same as `usize` ... but they already don't work...?

joshtriplett: Rust distinguishes those types, so if `size_t` were passed through FFI as `u32` on a 32-bit platform, you couldn't swap it with `usize`...

scottmcm: right but that only impacts platforms that don't currently exist?

joshtriplett: No, it would impact platforms that do exist today. The practical consideration is that people are using `usize` to mean `size_t`, which seems obviously correct ("it has size in the name"). But if we tell people "you're wrong, and you should be using `std::ffi::size_t` (which would have to be stabilized, but it's blocked on this issue)", that would be a lot of churn. Just like it'd be a lot of churn to say "you can't store a pointer sized integer value in a `usize`". Both are observable today and people are doing both of them. The question is do we break one or both of those or declare them to be correct.

scottmcm: I think what I'm trying to say is, if we need a type bigger than `size_t` for some platform, and that type alias was `usize` on all our current platforms, but on other platforms it becomes `u128`, that would not break the current platforms.

joshtriplett: yes but it would require us to allow for that assumption to be different on other platforms.

... we're going too deep into this question.

joshtriplett: the idea is in order to give people more confidence that what they are doing is correct, or decide that it is actively wrong, we need to make a decision about what we might allow in the future, or what we commit to not allowing in the future. I think we'd get value about deciding to commit to having `usize`.

nikomatsakis: This seems like a case where the mythical portability lint could help. I'm not ready to say "We don't support CHERI", but people writing on mainstream targets should be able to make assumptions.

joshtriplett: Would love to see the `where Target: xyz` proposal move forwards, with a lang change to allow declaring that requirement for a crate.

nikomatsakis: it seems like we are driving towards a proposal for a "portability lint 2.0" that has this as an example use case, I'd be happy if we closed this proposal in favor of a slightly broader proposal driven by mara/josh and with these folks as stakeholders.

scottmcm proposes a wild idea: what would it take for the C FFI types to be newtypes instead of aliases? Any code I write with `cint` has the same problems, right?

joshtriplett: std 2.0 in terms of the amount of breakage (:gasp:). I don't think code you write with c-int has these problems since you expect c-int to be a size that varies by architecture. The reason `core::ffi::c_int` (just added!) exists is to say "I want the thing C calls an int, which I am not assuming is a fixed size". You can say "I only want to run on platforms where c-int is 32 bits."

scottmcm: since nothing protects you from making it, I would assume that assumption is made pervasively, just as it is in C

joshtriplett: quite possibly. That would be something where we could add a portability lint to help you catch that, but we might not want it on by default, since that would break a lot of code for cases that largely don't exist outside of 16-bit platforms.

lokathor: practicality issue as well, since C code is not consistent, since casting between integers is automatic. new types would be much harder to use in Rust.

joshtriplett: I think we should invite a proposal re: portability.

nikomatsakis: agreed, some minimal declarations to give folks confidence, and saying we plan to definitely resolve via portability, would be ideal

joshtriplett: going to take an action item to invite somebody from libs (e.g., mara) to explore "crate-level `where Target: ...` kinds of things".

scottmcm: a lot of unknowns, we'd need a concrete proposal.

### "Positional Associated Types" lang-team#126

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

joshtriplett: Starting a conversation next week with a researcher about usability testing.

nikomatsakis: let's also think about general guidelines for how to assess these kinds of questions, since they come up semi-regularly

### "Heap allocations in constants" lang-team#129

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

Close, deferring.

const-eval still working on this, but this topic is not ready for a lang-team design meeting.

### "Interoperability With C++ Destruction Order" lang-team#135

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

### "inner crates, aka multiple crates per file" lang-team#139

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

### "allow construction of non-exhaustive structs when using functional update syntax" lang-team#143

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

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Tracking issue for `const extern fn` and `const unsafe extern fn`" rust#64926

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

### "Stabilize `let else`" rust#93628

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

still blocked on temporary rules, consistency of `let` and `let else`

semicolon:

> Several people have independently made the point that most braced blocks of code in Rust don't require a trailing semicolon, and that people are likely to regularly forget this. I'm finding myself starting to agree with that opinion.

scottmcm: every time I use this I go "why is it there", I know the answer, not against it, particularly since we can remove it later, but ...

joshtriplett: how confident are we that we can always do it later?

scottmcm: quite confident because it only appears in blocks; if you put a semicolon after the let, you get an empty statement, and let cannot be a trailing statement in the block since it is not an expression.

joshtriplett: not opposed to removing semicolon, but want to know if it's blocking...

nikomatsakis: I'm opposed to removing it if we don't also remove it from `let`

joshtriplett: how would that even work?

nikomatsakis: I don't think it would, which is why I don't want to remove it :)

nikomatsakis: I feel it will be surprising that you have to delete the else and add semicolon when changing from a pattern

let Some(x) = ....
else { return; }; // the second ; feels odd to scottmcm

nikomatsakis: not dead against removing the `;`, but I'd rather go forward as is and then evaluate in a narrow fashion whether to remove it via some experiments or something

scottmcm: diagnostics will also be helpful, if we get a billion questions about forgetting the semicolon

nikomatsakis: what annoys me more is that I need a block in the first place, I usually want to just say `else return`

joshtriplett: would you like to invite someone to do an initiative?

nikomatsakis: I think it'd be nice, but I wouldn't have bandwidth to second it

### "Always evaluate all cfg predicate in all() and any()" rust#94295

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

joshtriplett: check your boxes niko/felix, or speak up if you don't want this

## Active FCPs
### "Tracking Issue for RFC #2972: Constrained Naked Functions " rust#90957

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

### "proc-macro: Stop wrapping `ident` matchers into groups" rust#92472

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

### "Stabilize ADX target feature" rust#93745

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

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

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

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

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

* seconded by nikomatsakis -- action item for nikomatsakis to create tracking issue!

### "Positional Associated Types" lang-team#126

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

* seconded by josh triplett

### "Heap allocations in constants" lang-team#129

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

proposed to close by nikomatsakis-- close.

tl;dr: the next steps

### "Interoperability With C++ Destruction Order" lang-team#135

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

* seconded by cramertj

## P-critical issues

None.

## Nominated RFCs, PRs and issues discussed this meeting

### "Tracking issue for Allow a re-export for `main` (RFC 1260)" rust#28937

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

allows you to do

use crate::main

or

use submodule::main

to supply main. Useful for some embedded crates.

simulacrum: compiler team was a bit concerned that it had no actual use, josh do you know of actual use?

joshtriplett: I've definitely seen people *request* this, I'd have to do some digging to find it.

lokathor: how would a library's main function call your code?

joshtriplett: globals, exported symbols

simulacrum: could be a submodule, too

joshtriplett: right, that's another case where folks have wanted it. I've seen people want to do `#[cfg(target1)] use submod::main; #[cfg(other_target)] use othermod::main;`

jlusby42: How is this different from having your own locally defined `main` with cfg-arms that call other functions?

joshtriplett: boiler-plate and people generally expect use to "bring in a thing with the given name". Not that you can't work around it. No massive functionality missing, just a "nice to have".

nikomatsakis: basically says "there has to be a name `main` bound at the root of the crate, whether it be imported or defined explicitly"

scottmcm: if the compiler people felt this is a pain, I'd say "remove it", if it's easy, then "sure"

joshtriplett: from what I saw it required removing an assumption in one place but otherwise compiler folks were happier to have this supported than to have the `#[main]` attribute, which was removed as a result

nikomatsakis: no strong opinion, but it feels like the model of "there's an implicit call to something call `crate::main`". I do think having at least a single user would be nice. Let's make sure there's at least some!

joshtriplett: can you comment to that effect?

### "Parse and accept type equality constraints in where clauses" rust#20041

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

joshtriplett: Felix says that "@jackh726 says that niko has had some concerns regarding arbitrary where clause equality constraints", would Niko like to comment directly?

nikomatsakis: I do have some concerns. Adding in arbitrary equalities like `A = B` raises up the logic into a more complex thing. It's true that you can do `where T: Eq<U>`, `trait Eq<X>` `impl Eq<Self> for Self`, but that's not quite the same as `T = U`, because you don't necessarily the compiler to understand that `T: Eq<U>` implies `T = U`.

joshtriplett: Couldn't you do `trait UniqueName; impl UniqueName for RHS; ... where LHS: UniqueName`

nikomatsakis: Example that people might want to work

fn foo<T, U>(t: T)
where
    T = U,
    U: Debug,
{
    println!("{:?}", t)
}

scottmcm: I've tried to use it to extract type parameters...

nikomatsakis: the fundamental reason this is harder is that things you used to be able to infer, e.g. `?X = i32` is only true if `?X` is `i32`, but not if you have `where i32 = u32` in the environment. That's already true for assoc types, so it may not be that significant, but at least it's constrained to assoc types then. But I can't remember all the details of this right now.

nikomatsakis: maybe we could accept it but narrow it to `T::Item = u32` instead of `T: Iterator<Item = u32>`, then it is just more convenient and leaves door open for later

pnkfelix: issue #20041 literally uses that kind of example, wanting to check for iterator items

joshtriplett: Should we defer this to WG-traits?

### "Lazy tait take two" rust#94081

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

https://github.com/rust-lang/rust/pull/94081#issue-1141371871

user visible change 1: RPIT inference from recursive call sites

fn bar(b: bool) -> impl std::fmt::Debug {
    if b {
        return 42
    }
    let x: u32 = bar(false); // this errors on stable
    99
}

user visible change 2: divergence between RPIT and TAIT in return statements

fn bar(b: bool) -> impl std::fmt::Debug {
    if b {
        return vec![42]
    }
    std::iter::empty().collect() // Works, magic (accidentally stabilized, not intended)
}

type Foo: Debug;
fn bar(b: bool) -> Foo {
    if b {
        return vec![42]
    }
    std::iter::empty().collect() // Error
}

upshot:

* Niko to try and write a document that outlines what each change *means* (upside, downside) and
* to distinguish "change in behavior from stable" vs "interesting fact"