---
# System prepended metadata

title: Unconference Topics
tags: [meetup-2024]

---

---
title: "Meetup 2024: Unconference topics"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-09-10
url: https://hackmd.io/UO7F1gkCT--ah8pUknQRsg
---

# Meetup 2024: Unconference Topics

- [Expanding dyn-capability](/l_EJFwlsT8KojFQIY-HoOQ)
- [Effects and associated effects](https://hackmd.io/Oc8QQ8yGRcKvkicLh7kisg)
- [Linear types](/W50y43HnRQifRNeoGcVUag)

## Unconference voting

Preparation: Add topics that might benefit from in-person discussion as you think of them. We'll vote on topics several times during the meetup.

| Item                             | TC  | NM  | JT  | FK  | TM  | SM  | Total |
| ----                             | --- | --- | --- | --- | --- | --- | ----- |
| expanding dyn-capability         | +0  | +1  |     | +1  | +0  | +1  | 3
| Effects and associated effects   | +1  | +1  |  *  | +1  | +1  | +0  | 4
| Linear types.                    | +1  | +1  |  +1 |     | +0  | __  | 3
| Ergonomic captures (`.use`)      | +0  | +0  |     |     | +1  | +0  | 1
| async closures bikeshed          | +0  | +1  |     |     | +1  |     | 2
| Revisiting design goals          | +0  |     |     |     |     |     | 
| `is` and `let`-chains            | +0  | +0  |  +1 |     | +0  | __  | 1
| T-design                         | +0  | +0  |     |     |     |     |
| Paid staff for lang (or design)  | +0  |     |     |     |     |     | 0
| module level generics            | +1  |     |     | +1  |     |     | 2
| `yeet` stable?                   | +0  | +0  |  +1 |     |     | +1  | 2
| Try blocks (combine with above?) |     |     |  +1 |     |     |     | 1
| One True raw pointer/`&'unsafe`  | +1  | +0  |     |     |     | +1  | 2
| `_::Foo` & co                    | +0  | +0  |     |     | +0  | __  | 1
| Named parameters or structs?     | +0  | +0  |  +0 |     | +0  | +0  |
| Specialization                   | +0  |     |     | +0  | +0  |     | 1
| Triage! (avoid getting behind)   | +0  |     |     |     |     |     | 0
| Const all the things             | -0  | *   |     |     |     |     |
| move-only fields (e.g. niched)   | +0  |     |     |     | +0  | +1  | 1
| `&own` (reference w/ destructor) | +0  |     |     |     | +1  |     | 1 
| new process and rustbot          | +0  |     |  +1 |     |     |     | 1

* -1 no
* -0 leaning no
* +0 leaning yes
* +1 yes
* \*  mildly concerned we don't have the right people

Process proposal:
Note the items that got 3+ and the items that got 2+
Figure out how much time we have. Figure out an amount of time such that we can spend a full block on 3+s and a partial block on 2+s
If multiple items proposed by the same person are tied, proposer's choice

## Brainstorm area

You may optionally use this section for brainstorming.

:::spoiler

* Items from vibe check that got a positive vibe and people were interested in talking more.
* Project process items
  * establishing a T-design
  * establishing a paid person/team to get small tasks over the finish line
* Try blocks - getting them over the finish line
* Const-ification
* Specialization, nbd
* String literals work with string type
* `&own`, Cow, dyn
* Module-level-generics and existential types oh my
* Async closures

:::

## Ergonomic captures (`.use`)

Workshop some of the questions embedded in this RFC.

## Revisiting design goals

Let's discuss what we learned during the meetup about the design goals and make some revisions.

## Project process items - establishing a T-design; establishing a paid person/team to get small tasks over the finish line

- 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

## "Module-level generics"

## Async closures bikeshed

## "Specialization--"

Cover some of the latest around specialization

## Easy dyn-capable improvements?

* What makes traits not dyn-capable? How can we fix it so that they are?
    * E.g. `dyn Iterator<Item=ConcreteType>` is (sometimes) unfortunate
    * If all I really want is `dyn Iterator<Item=dyn ItemBound>` (in effect; or maybe `dyn Iterator<dyn* ItemBound>`, not sure...), can we make that easier for people to reach for?
    * also, trait methods with generics will immediately be non dyn-capable. Can we expand things (namely for `fn method(&self, impl Bound)`) so that *that* is at least supported via some dyn magic.

## My topic here
