# Agenda for pre-RustConf lang summit (DRAFT)

:::danger
:radioactive_sign: **This is a public document, don't include private personal information or logistics information.** :radioactive_sign:
:::

(This is a preliminary sketch/draft of possible agenda items for the pre-RustConf lang summit.)

Recommendation: time-bound all items, do explicit time checks and make explicit decisions to continue or move on; otherwise, nerdsniping, bikeshedding, and other attractors will likely make a small number of items consume the entire time.

Neither sections nor items within sections are in priority order. In particular, we shouldn't prioritize everything in "Process" above everything in the "Long-standing ..." sections, as tempting as that may be.

[TOC]

## Process

Process/Bikeshed attractor warning: some of these topics seem especially likely to become time sinks.

- Should we establish a "design team", a parent team of T-lang and T-libs-api and (portions of) T-cargo and likely others with substantial design components?
- Handle overlapping items, host design meetings, accelerate coordination of items that would otherwise play ping-pong with round-trip latencies of weeks
- Should we establish/hire/pay a group of one or more people we can delegate small tasks to?
- Goal: have a default way to handle things that need a few hours or a few days to complete.
- Small bits of design or similar iteration on something we care about seeing finished in a timely fashion
- Simple experiments
- Process automation
- Leadership Council budget
- New decision process and its automation
- We've had draft implementations for a long time, we should review/test them and figure out what it'd take to deploy them
- Could we auto-start decisions on e.g. T-lang RFCs?
- Could we let anyone in the project start a T-lang decision?
- Handling changes that draw community pile-ons / :-1:s
- How do we balance design experiments with the potential for "establishing facts on the ground" / building momentum towards particular alternatives?

## Values, design axioms, Rust philosophy

- "I would like to draft an RFC laying out design axioms for Rust as well as representative personas. I'd like to discuss this with the team early on to see if it indeed provides a useful framework in the discussions that follow. If so, I'd like to move it towards an open RFC." - nikomatsakis
- High-level and low-level Rust, "registers", "dare to ask for more" - nikomatsakis

## Long-standing items that require consensus check or design discussion/iteration

Items in this section have had substantial design work, and *may* be relatively close to the finish line. These items may benefit from doing an explicit consensus check or vibe check.

- Externally implementable functions/statics/traits/etc ([RFC 3632](https://github.com/rust-lang/rfcs/pull/3632), [RFC 3635](https://github.com/rust-lang/rfcs/pull/3635))
- Distributed slices, and how we want to handle them in various linking scenarios
- `cfg(accessible(...))` and `cfg((version(...))`
- Can we get both of these over the finish line?
- Ergonomic ref-counting (if anything is blocking it)
- Postfix macros (`expr.mac!(args)`) ([RFC 2442](https://github.com/rust-lang/rfcs/pull/2442))
- Extending format args to support `dotted.exprs`
- Is this lang, libs-api, or both?
- Do we want to go any further, or draw a firm stopping line?

## Long-standing language problems that still need substantial design/brainstorming

These may benefit from clarifying the problem statements, figuring out how much consensus we have on the problems, and/or whiteboarding potential solutions.

- The "only one possible impl" inference rule, and the inference breakage it causes. Should we consider changing that in a future Rust edition?
- Note for this: some surprising things, like `arr[some_usize_expr]`, may depend on this
- Should figure out what it'd take to try some experiments here
- Lint group for "I'm a popular library, please warn me about convenience/future-proofing tradeoffs and help me favor future-proofing"
- Esteban Kuber is experimenting with possibilities in this area
- Module system usability improvements: making `mod` unnecessary/optional, inferring modules from the filesystem, etc.
- Note that David Barsky from rust-analyzer will be at RustConf if we want to cross-check anything with r-a.
- Do we want a language (or library) mechanism for [tap](https://docs.rs/tap/latest/tap/)-style chaining?
- Keyword arguments (both "whether" and "how"), or more generally, what do we *want* people to do for complex function invocations?

## Discussion items that defy categorization

(Section added to allow for brain-dumping items into the agenda before categorizing them.)

## Relaxing and socializing

- Group photo?
- Dinner?
- Board games?