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