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