---
title: Triage meeting 2021-12-14
tags: triage-meeting
---

# T-lang meeting agenda

* Meeting date: 2021-12-14

## Attendance

* Team members: Josh, Scott, Niko, Taylor, Felix
* Others: simulacrum, Lokathor

## Meeting roles

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

## Scheduled meetings

* Dec 15th: Lang team check-in
* Dec 22nd: Unclear
* https://github.com/rust-lang/lang-team/issues/129

## Announcements or custom items

* nikomatsakis has been working on a document about dyn upcast:
* https://rust-lang.github.io/dyn-upcasting-coercion-initiative/design-discussions/upcast-safety-2.html
* [Zulip chat](https://rust-lang.zulipchat.com/#narrow/stream/144729-wg-traits/topic/dyn.20upcasting.202021-12)
* joshtriplett: RFC pull request was just made to rename Stream to AsyncIterator: https://github.com/rust-lang/rfcs/pull/3208/
* Not directly a lang item, but intersecting interests of a lot of people here!

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

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

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

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

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

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

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

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

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

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

## PRs on the lang-team repo

None.

## RFCs waiting to be merged

None.

## Proposed FCPs

**Check your boxes!**
### "Tracking issue for RFC 2115: In-band lifetime bindings" rust#44524

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

### "Change location of where clause on GATs" rust#90076

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

## Active FCPs
### "Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586

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

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

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

* This is basically all set but we just need to create the real tracking issue.
* There is a repo with actual content https://rust-lang.github.io/negative-impls-initiative/

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

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

* Needs a tracking issue, too.

## P-critical issues

None.

## Discussed RFCs, PRs, and issues

### "Relax priv-in-pub lint on generic bounds and where clauses of trait impls." rust#90586

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

In FCP, doesn't need to be nominated. Nomination removed.

### "Make specifying repr optional for fieldless enums" rust#88203

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

* One of that "group" of things we've been looking at.
* jswrenn was going to "say something" here but pnkfelix didn't finish following up yet.
* [jswrenn does have a long comment here](https://github.com/rust-lang/rust/issues/60553#issuecomment-984290718)
* Removing nomination as the next immediate step is the action item.

### "Allow using $:literal containing integer to index into a tuple" rust#91166

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

* Discussed previously, petrochenkov and dtolnay are in discussion.
* nikomatsakis: I agree with the goal as described in the PR header
* joshtriplett: should we post a statement that we agree with the goal but would like dtolnay/petrochenkov to figure out the best strategy
* scottmcm: feels like the kind of thing where "if petrochenkov/dtolnay agree, I would agree"
* pnkfelix: they don't yet, right?
* joshtriplett: no, they both understand how it works, and are disagreeing about the best next step
* pnkfelix: what about the behavior of `0.0`?
* nikomatsakis: `x.(0)` is another edge case that petrochenkov raised
* joshtriplett: I don't think he was suggesting it should work,
* scottmcm: I'd like to discuss the float thing. I'm not sure what my "mental expectation" is here....
* nikomatsakis: that gives an error, and dtolnay
* scottmcm: but why is that an error, and how is it different from 0?
* nikomatsakis: but 3 levels is definitely an error, right?

macro_rules! m {
    ($thing:ident . $float:literal) => {
        $thing . $float
    };
}

fn main() {
    let x = ((('x',),),);
    let _ = m!(x.0.0.0);
}

* nikomatsakis: I think that my 'mental model' for how `x.0.0` works is that `0.0` is a bunch of small bits that are built up into a `f32`
* joshtriplett: I don't think that is how it works today
* nikomatsakis: yeah, and I think we can't fix that easily (because proc macros can see the difference etc)
* nikomatsakis: there is no backwards compatiblity question here, right? specifically, it will always take the same arm, it's just a question of whether the match arm gets an error once it compiles.
* joshtriplett: potentially a *surprising* gap then, but not back compat.
* scottmcm: I think I would not expect floats to work, but by that same logic I don't expect ints to work
* nikomatsakis: what happens with tt.... this works

macro_rules! m {
    ($thing:ident . $float:tt) => {
        $thing . $float
    };
}

fn main() {
    let x = ((('x',),),);
    let _ = m!(x.0.0);
}

pnkfelix ``$(tt).+``: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c3331fa3b172f545d3b54e043078f80c

* nikomatsakis: it fails because of the synthetic parens we introduce to manage to avoid `$a = a + b` having weird behavior here..

macro_rules! m {
    ($a:expr) => {
        $a * 3
    };
}

* nikomatsakis: I think I agree with scott that either you can see a literal as equivalent to its underlying token or you can't; so the `0.0` example should work
* simulacrum: I could see it being somewhat different. A `0` is kind of viewable more as an "identifier" than a float to me. I feel like accepting `0` as a token allows you to do whatever you want, but accepting it as a literal you have to use it as a literal.
* nikomatsakis: I'm not sure if dtolnay is fixing the problem the right way
* cramertj: it seems like they're not trying to match a literal, that's the wrong way to do that thing
* pnkfelix: as in, what should the category be for the projection argument?
* cramertj: right, they're literally not matching a literal here, they're matching a "post expression selector" or something --- you could imagine something that supports indexing operations, for example. I assume they didn't intend to support that here, but it seems like they're trying to do a specific custom thing that isn't what literal is for.
* scottmcm: certainly I wouldn't expect `0.0e0` to work
* joshtriplett: Or `tuplename."string literal"`
* nikomatsakis: it may be that they're trying to have different arms for "tuple field" vs "other field", and hence they're not using `tt`
* the main reason I can see to not use tt is if you really want *tuple fields* here
* cramertj: even so, it seems like literal is not what you want, it's a hack to get that behavior
* nikomatsakis: I feel like the right fix is new forms of fragment specifics for different kinds of field names
* e.g. named field, numbered field, method call, etc
* code snippet: https://github.com/dtolnay/anyhow/blob/1.0.51/src/ensure.rs#L306-L312
* pnkfelix: we should go back to dtolnay and see what the use case is
* joshtriplett: who will summarize into the issue?
* scottmcm bravely steps up :superhero:

### "remove pref_align_of intrinsic" rust#90877

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

* Lokathor: I recall the result of last meeting was "leave this on nightly, why the urgency"
* can we comment on this and un-nominate?
* it has a use case (c2rust)
* nikomatsakis: I'd be ok with that, I'd be opposed to removing it unless there's a good alternative to that use case
* joshtriplett: if someone argues it can't be stable, that'd be another good argument to remove, but not obvious why we couldn't stabilize it
* Action Item: joshtriplett to summarize and de-nominate

### "Unreachable code is not borrow-checked" rust#91377

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

* nikomatsakis: I think this is working as designed, for better or worse, it was hard to decide precisely what set of errors you were going to get in code like that and we decided to just run with it.

### "Mark defaulted `PartialEq`/`PartialOrd` methods as const" rust#91439

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

* Adds a (perma unstable) `#[default_method_body_is_const]` attribute
* We believe the behavior of this is
* whole trait impl can be marked const (or not)
* this attribute means "if the whole impl is marked const, this default won't break it"
* i.e., you get to assume current trait impl is const, and you check that fn is const under that assumption
* cramertj: alternative would be track which methods get called and know that it is const if those functions are const
* lokathor: I believe individual const fns off of the trait would be a potential future extension
* cramertj: right, but that's probably soemthing we want, right?
* joshtriplett: all this issue is asking us is
* are we prepared to commit to the idea that if you impl Eq and you `eq` method is const...
* cramertj: ...but that's not actually the condition, it's actually whether the impl is const
* nikomatsakis: I also don't think there's any commitment; if we stabilized const impls, then we would be committed, but we haven't yet
* joshtriplett: second paragraph:
* "if we stabilized any const traits that used this feature, we're commiting to having this mechanism or some other mechanism that makes this feature possible"
* "in the meantime, until we stabilize a const trait, we're not committing to anything"
* nikomatsakis: I'd like to know how we're recording these kinds of implications, I know there's a repo
* joshtriplett: do we need an FCP or just :thumbsup:
* nikomatsakis: I think a :thumbsup: suffices, this feels like a "check in" from active initiative that doesn't require full consensus
* joshtriplett: then perhaps we should ask the question of where the assumption is recorded that we need to evaluate this before stabilizing const trait impls
* nikomatsakis: let's say we're good with it as long as the assumptions are recorded somewhere for future evaluation
* simulacrum: I want to write a comment!
* joshtriplett: No me! I'm already writing it!
* nikomatsakis: :brain-exploding: 🤯 ETOOMANYVOLUNTEERS?! what just happened?!

### "New declarative macros, functions and fields not being recognized" rust#91249

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

* nikomatsakis: Seems like this is saying "we need an RFC for hygiene, it is clear that strictly saying 'all names are local to the macro' is going to be confusing when you have non-lexical lookup like this one".
* joshtriplett: I feel like we should tag this as the tracking issue
* nikomatsakis: I feel like this is obvious-- how is type-based dispatch going to work. Also how are things non-hygienic.
* joshtriplett: well, you might want to have methods that are "hidden" outside the macro, right?
* scottmcm: isn't that a fn?
* nikomatsakis: not necessarily, but I feel like if I were going to enumerate a list of things, I would defintiely have put "type-based dispatch" on the list of things to consider.
* scottmcm: I think that because I can call (or implement) a trait method without having imported its name specifically, it doesn't feel like a hygiene issue to me.
* joshtriplett: we need to link this from macros 2.0 tracking issue and either close it or leave it open, but de-nominate it.
* https://github.com/rust-lang/rust/issues/46342 is basically the same bug, just different context
* see also https://github.com/rust-lang/rfcs/pull/2498

## Nominated RFCs, PRs and issues