---
title: Planning meeting 2022-02-02
tags: planning-meeting
---

# T-lang planning meeting agenda

* Meeting date: 2022-02-02

## Attendance

* Team members: Niko, Josh, Felix, Scott
* Others: Mara, Michael Goulet

## Meeting roles

* Action item scribe:
* Note-taker: Josh

## Proposed meetings
- "Non-terminal divergence between parser and macro matcher " [lang-team#111](https://github.com/rust-lang/lang-team/issues/111)
- "lang team check-in" [lang-team#128](https://github.com/rust-lang/lang-team/issues/128)
- ""things other teams want"" [lang-team#130](https://github.com/rust-lang/lang-team/issues/130)
- "Lint policy" [lang-team#132](https://github.com/rust-lang/lang-team/issues/132)
- "Plan for enum discrim, repr, and casting" [lang-team#134](https://github.com/rust-lang/lang-team/issues/134)
- "A path towards stable generic const expressions" [lang-team#138](https://github.com/rust-lang/lang-team/issues/138)
- "Astrologic chart (aka roadmap)" [lang-team#140](https://github.com/rust-lang/lang-team/issues/140)
- "Never type next steps" [lang-team#141](https://github.com/rust-lang/lang-team/issues/141)
- "impl trait overview" [lang-team#142](https://github.com/rust-lang/lang-team/issues/142)

## Schedule

* Feb 9th -- Backlog bonanza
* No doc required
* Feb 16th -- libs team sync / [lang-team#130](https://github.com/rust-lang/lang-team/issues/130)
* Mara/Josh to make doc
* Feb 23rd -- "Never type next steps" [lang-team#141](https://github.com/rust-lang/lang-team/issues/141)
* Mark/Niko to make doc

+1: Niko, Felix, Josh, Scott

### Josh proposes

- ""things other teams want"" [lang-team#130](https://github.com/rust-lang/lang-team/issues/130)
- "Never type next steps" [lang-team#141](https://github.com/rust-lang/lang-team/issues/141)
- Backlog Bonanza

### Niko proposes

- "Astrologic chart (aka roadmap)" [lang-team#140](https://github.com/rust-lang/lang-team/issues/140)
- Felix: Does it make sense to do the kickoff synchronously, or to do this asynchronously?
- Josh: Could we use the remainder of planning meetings to do this (today, or March 2)?
- Niko: convinced that we should run this asynchronously
- Josh + Niko to help drive this asynchronously this month
- "impl trait overview" [lang-team#142](https://github.com/rust-lang/lang-team/issues/142)

## Active initiatives

See the [initiative project board](https://github.com/orgs/rust-lang/projects/16/views/1)

## Astrological chart

pnkfelix: been doing similar work for compiler team, some things came up that are "lang adjacent". Themes I identified from people's suggestions (for *compiler team*, not lang):

* Improving Rust developer experience
* Improving compiler contributor experience
* Delivering on Rust's promise
* Gap between what we deliver today and what we want, and how can we make it smaller

pnkfelix: Lang team things that arose in my mind:

* Memory model, unsafe code guidelines -- don't know if that's plausible for 2022, but if there are stakeholders who want to help, would be great to coordinate with them
* Implementation details -- trait system, chalk and what not

nikomatsakis: strong agree on unsafe code, that fits with work I wanted to do of creating a model for MIR ("patina")

nikomatsakis: work going on in async land

nikomatsakis: ergonomics, especially around "where clauses" and "lifetimes"

pnkfelix: what about formal methods folks?

nikomatsakis: they need the model, esp as it extends to operational semantics of MIR

pnkfelix: what about fuzzing? might a grammar help there?

nikomatsakis: possibly

nikomatsakis: what about things like "try", try trait, error handling

scottmcm: still on me or someone writing up proposal

nikomatsakis: level of detail for this document? specifics? themes?

pnkfelix: the themes seem right, but I think having concrete examples is also important, so people know what it is, but also be clear that "if there's something important in this space"

nikomatsakis: shape I would most want is "experience we're looking to create in these areas, here are some ideas for how to move us there, if you have other ideas want to hear them"

pnkfelix: there are very concrete tasks oriented around improving contributor experience for compiler team, that needed to be teased out, is there something analogous for lang team? do organizational details really belong here?

joshtriplett: Language improvements that help the project and community scale. e.g. cfg-accessible lets crates/libs evolve in a co-designed way. Things that allow versionining and getting more value out of editions for libs, not just for lang. Any number of things in this space? There are ways in which our overall community has pressures to "not try out" different things. For example, language reasons why there is only one serde and it's hard to have more than one. Reasons why if you want to make thing X work for thing Y, have to do it as part of X/Y, hard to make the two work together (coherence). Kind of thing where, if we had language level solutions for some of those problems, helps us all scale better. Seems like around the right time for us to do that kind of thing, we are scaling rapidly.

nikomatsakis: reminds me of extensible rust ideas, which I thought of as more compiler, but is really also lang, e.g. custom error messages, lints, and things in libs.

joshtriplett: giving other people the tools we in the rust-lang rust repository have. We haven't thought for years about possibility of stabilizing the stability markings, only our tool, nobody else gets to use them, but library might like to have the equivalent of stability markings, the ability to ship nightly APIs that people have to explicit opt in to. That kind of thing.

scottmcm: I'd love to look at patterns of lints we have and try to phrase them as attributes other people can start to use, e.g., if you call this with a `0` it will panic.

joshtriplett: gcc actually has attributes for that sort of thing (e.g., must be non-null). Niches are another case, we haven't stabilized any mechanism to specify niches, so we get special optimization mechanisms that are easy for us to use, but people outside libstd would have to fake.

pnkfelix: we can probably have a whole section dedicated to things that we've hacked in for internal use and would like to see exposed. My personal bug-a-boo is may-dangle. You can't have collections outside libstd that express cyclic structure.

scottmcm: for me, literal type inference-- how can we have `1` be not just u32 or i32 but also bignum or NonZeroU128.

joshtriplett: haskell has "rebindable syntax" that allows literals to desugar to be a trait call. could imagine a trait for that, ideally that leverages const. Also some reasons to be careful there, you can create confusing code, haskell has had some experiences with that. We've managed, even thought we have overloadable operators, to have people overload them in surprising ways. Maybe that's the little hints, like that we called it "add", and not "plus", but something has produced social pressure to not do that. Whatever we can do to avoid excessively clever patterns.

nikomatsakis:
* async-io: we have coverage,
* embedded/low-level hacking: failed to really cover this -- maybe kernel hacking too!
* portability (esp. across phones): partial coverage
* high-assurance (comes back to unsafe code guidelines)

nikomatsakis: to phrase this another way, the reasons I hear people adopting rust are these

* performance (without losing safety)
* able to target low-level niches (while gaining safety, ergonomics)
* portability across many languages, platforms (e.g., one library that targets everything)

pnkfelix: Maybe targeting dynamic code generators?

Mara: isn't that mostly library?

nikomatsakis: also webassembly, I've been targeting it lately, once it works it's great, but getting it to work feels like it involves some magic

scottmcm: maybe there's a way to survey what people do in build.rs scripts or proc-macros that feel like hacks, but that's what they do because it's what they have to do?

mara: one thing that comes up often in low-level code is something like RFC #2492 (existential types with external definitions), basically a way to generalize and allow any crate to define "something other crates need to define". Don't just say "stdlib needs an allocator" you can say "my crate needs a something". This would solve a lot of the horrible hacks I see in embedded all the time.

joshtriplett: definitely an example of tools we have but didn't generalize. We made a tool for "global allocator", but not a generalized tool for "global Thing".

mara: I would love to be able to say "we need a filesystem but it's provided by another part"

scottmcm: linkme/distributed-slice came up recently, that would be very nice

joshtriplett: tie-in to a feature of webassembly, their approach to module linking is designed to support the case, web assembly does the generalized version of that, where you specify your external deps, and the host gets to decide what you get to complete that dependency. So e.g. you can provide a virtual file system. This is even, to some degree, scoped.

nikomatsakis: This is why I brought up the scoped capabilities system yesterday, I'm nervous about people creating lots of non-compasable things.

joshtriplett: as long as there is a way to make it sufficiently global so you don't have to explicitly or implicitly pass it everwhere, it seems fine. It should be *easy* to do globally, too.

mara: keep in mind that in embedded and kernels, global is very normal and expected.

nikomatsakis: yes

barsky: useful for mocking and testing. Would love to improve ergonomics of loom.

nikomatsakis: speaking of tools we have kept for ourselves, the whole testing/benchmarking system is kind of hard-coded, though cargo lets you do a lot of things, it'd be good if you could easily "run my tests with loom" and so forth. Right now `#[test]` is very hard-coded in terms of what it does, might be cool if it could do more.

joshtriplett: the other day libs was talking about the `Termination` trait; it's not stable yet, but it has stable impls that people count on. There's an impl for `Result<_, impl Debug>`. It doesn't require `Error`, it would be useful if we could say "here's a better impl if you have impl Error rather than impl Debug". Rather than specialization, it might help if we had the ability to do dynamic downcasting here -- "do you impl Error"? Not obvious that we have the facilities to support that right now.

nikomatsakis: I was going to bring up specialization but I hadn't because it was a specific feature. Downcasting would be helpful, but it messes with parametricity, and I recently found a reason why parametricity is important.

joshtriplett: how do people feel about the overarching theme of "scaling" and giving other people the tools that we have?

pnkfelix: doesn't cover unsafe code, but we can have multiple themes

joshtriplett: I don't think everything has to fit in one theme, but I do see a connection, people outside can't count on how the compiler behaves, but internally we sometimes lean on that since we know what compiler will do...

pnkfelix: ...we do? ;) I get it, the compiler / libstd are coupled and we rely on that sometimes. Documenting and fixing standards enables the community to do more of what libstd can do.

mara: also a thing we want to do in the lib team, reducing the number of unstable features we depend on, I think we have >100 features. That matches very much with this theme.

joshtriplett: yes. we might like to generally decouple lib from compiler/lang, so that they can be used more independently.

mara: makes it much easier for people to work on new proposals as a crate, since many things literally cannot work outside the stdlib.

Next steps: Josh and Niko to build a template roadmap and include many of the above items in it, and then work asynchronously with the whole team to finish it.