---
# System prepended metadata

title: Triage meeting 2021-12-21
tags: [triage-meeting]

---

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

# T-lang meeting agenda

* Meeting date: 2021-12-21

## Attendance

* Team members: Niko, Josh
* Others: simulacrum

## Meeting roles

* Action item scribe: simulacrum
* Note-taker:

## Scheduled meetings

* Tomorrow:
    * [Heap allocation in constants](https://hackmd.io/JdKPGA2eQ_qSX13pQeKoNg)

## Announcements or custom items

(Meeting attendees, feel free to add items 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!**
### "Change location of where clause on GATs" rust#90076

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

* blocked on 'further thought' concern from Josh
* Niko:
    * still feel this should be changed but my urgency is not super high yet
    * I want to work through and do a general triage about this
* Mark:
    * User experience report that I was using GATs on betas and I was positively baffled why what I was trying didn't work
    * Eventually realized that the syntax we currently accept (before the `=`) was what I had to do
    * Despite being in the design meetings and so forth
* Niko:
    * That matches my experience
* Josh:
    * Can you share that experience on the thread?
    * Maybe point to some of the code or error messages?
* Mark:
    * I don't think it'd be *new*, but I can write up a short comment
* Josh:
    * Don't personally have an incredibly strong feeling, but I have a mild concern, I'm concerned about both possible locations for the where, in terms of ambiguity.
    * My main concern is that people on the thread have concerns. If I see folks on the thread no longer have it, I'm happy to drop mine.
* Niko:
    * I do think it's possible that this will just wind up being a controversial call, but that's ok.
* Niko:
    * I do have some further thoughts about GATs but I guess this probably isn't the right meeting for me to go into it, I realize now. I've been working through the RPITIT and implied bounds design and I think that it affects some of the other bits of the overall design (e.g., the default where clauses).
* Josh:
    * One other thought, one of the motivations is the desire to copy from the trait, add an equal sign, and type?
* Niko:
    * It is a common use case that people want to copy from the trait and add an `=` sign, but the difference is where you expect to add it.
    * Current design is that you would add it at the *end*, but the proposal would change it to placing the `=` sign more in the middle.
* cramertj:
    * It depends where you think people will expect to put it. I think it's rather formatting dependent. 
* Josh:
    * What is stable at the moment?
* Niko:
    * Nothing-- what is stable is type aliases with where clauses.
* cramertj:
    * But we probably want both to match.
* Niko:
    * Right, but they have the wrong behavior on type aliases (they get ignored).
* Josh:
    * I agree we want type aliases with where clauses to match -- it would be nice if they weren't ignored of course -- but if we get to the point of urgency on getting GATs stabilized, and this syntax question remains a blocker, as an option could we simply not support where at all, and just say that you need to put the angle bracket syntax?
* Niko:
    * Some common bounds wouldn't fit. The current design requires `where Self: 'a` on virtually every GAT you will use in practice:

```rust
trait Foo {
    type Bar<'a>
    where
        Self: 'a;
}
```


## Active FCPs
### "Tracking issue for RFC 2115: In-band lifetime bindings" rust#44524

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

* In FCP, no objections raised.

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

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

Action item:
- [ ] [2021-06-22]: Niko to merge/close negative impl coherence (Felix to liaision) https://github.com/rust-lang/lang-team/issues/96


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

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

Action item:
- [ ] [2021-11-16]: Felix to summarize discussion on https://github.com/rust-lang/lang-team/issues/126 (lang-team discussion, and zulip as well if possible) 
    - in particular, wanted to block on owner accepting investigation tasks.

## P-critical issues

None.




## Nominated RFCs, PRs and issues
### "Remove effect of `#[no_link]` attribute on name resolution" rust#92034

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

Points from discussion:

* Doesn't seem surprising that saying no-link can cause linker errors
    * This new behavior is more what we would expect
* We could make this more user friendly if it matters, but this is very rarely used
    * Josh can imagine there may be use cases, e.g. if you don't have dylibs on your system 
* Josh: Do we need a crater?
    * Mark: I suspect we'll catch it in the beta run. A quick search found that the vast majority of uses are rustc tests that got forked in random places and some old servo forks. Nothing current.
    * Josh: We should tag it relnotes, though, right?
    * Mark: Yes. In any case the beta run regressions wil get bisected and tracked to this.
