---
title: "Design meeting 2024-02-21: RfL"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-02-21
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/RfL.20meeting.202024-02-21
url: https://hackmd.io/ptbPieJ2ScqMCni7Pe3tEQ
---

# Discussion

## Attendance

- People: TC, Josh, tmandry, Miguel, Urgau, Santiago, y86 (Benno Lossin), CE, Alice Ryhl, Gary Gau, Wedson, Sid Askary

## Meeting roles

- Minutes, driver: TC

## Agenda

TC: What did we want to start on?

Josh: We first want to talk about the ongoing interaction structure. Then we want to identify items that we can go through them one by one.

https://hackmd.io/r556bZKeSdu0cWwurlHjpw

Miguel: We should start with the meta points. Do we want it to be public or should it be private? Should it be invite-only? We're fine either way. Niko had raised points about problems with too many people.

Miguel: If we make the notes public, that can inhibit people from companies from speaking freely. I'm aware that most meeting in the Rust project are public. But it may make sense to start more privately here, similarly for the minutes and the agenda.

Miguel: I know people suggested using an agenda generator. But nonetheless, I think we should have a separate agenda for the things we want to address.

Josh: (For clarity, not proposing we start with the agenda generator from day 1.)

tmandry: We should use a separate meeting link, not reuse the same one. In the Rust project we default to public for meetings. I know that's not the norm everywhere. Public in the Rust project often means semi-public. There's a norm that things are not widely advertised. My feeling is that works reasonably well.

Josh: I personally think we should default to semi-public. No-one is proposing to record this meeting. The minutes are recorded with appropriate discretion. Once we go down the road to defaulting the private, it becomes more difficult to pull in more people.

TC: +1.

Miguel: We could have other meetings that are public.

JT: Do you feel that more general private/candid feedback sessions is something we should put on the agenda?

Miguel: My proposal was to make this private and then we could do other things public.

CE: Do you really think that we're going to be discussing private things here? You're interfacing with the Rust Project where we do everything in the open. We should keep this in the semi-public space.

(CE left at this point.)

JT: Maybe we can talk through at some point how to accomodate both. We may want to have private candid discussion/feedback sessions, and conversely things like the feature discussion for how we solve RfL needs in the Rust language should start in public.

TC: Miguel, is this a blocker for you to move forward here on other issues?

Miguel: No, I'm just bringing up things that may be helpful for us.

tmandry: I understand what Miguel is saying. But I expect that the meetings, over time, will likely get smaller. Until then, what Josh is saying sounds fine.

JT: I want to acknowledge here that there may be some ambiguity about whether the RfL team is joining our meetings according to our standards or whether we're joining their meetings according to their standards. We didn't ever talk about that, and we should make sure we address that.

Sid: Can we get to the technical issues please?

## Results of poll on scheduling

Miguel: On our side, we could make it half an hour later if needed. It's up to you folks.

TC: Thanks for checking on that. We're still checking that on our side.

## CI

Miguel: I had a meeting about whether we could put RfL in the CI for Rust. I learned that Fuchsia is already in the CI for Rust.

tmandry: I can speak to that. It is in Rust CI. It was added a month or two ago. It's an excellent regression test for Rust.

tmandry: Fuchsia does not typically use unstable language features. We make light exceptions when things are close to stabilization, such as AFIT. We use some unstable compiler (not lang) features, as those are generally more stable.

tmandry: If we make a formal guarantee that we won't break features, we might want a way to test that guarantee. I could see putting RfL in CI as a reasonable path to testing those guarantees.

Miguel: That's something like what I was thinking.

## Rust LTS

Miguel: Please let us know if there are any developments on Rust LTS.

## Rust Liaison

Miguel: Please let us know if there are any developments on this.

## Unstable features

JT: I have a list of the features you're not yet using.

JT: So we could start there, but if you have a high priority item on something else, we could analyze those dynamically.

Miguel: We high priority is `Arc`. The other is `alloc`. But those are long discussions.

JT: So I don't know that we want to go deeply into those in this meeting. But we could talk about what the subset of people are that would help to address these issues.

Miguel: Alice and Wedson for `Arc`.

Wedson: +1, I'd like to be there.

JT: tmandry, thoughts on our side for who should be in that work stream, specifically for `Arc`?

tmandry: Probaby someone from opsem, and also Adrian Taylor given his work on the arbitrary self types v2. And CE.

TC: Do we perhaps want to dedicate the meeting in two weeks to one of these topics and then to be sure to get the right people there for that?

JT: Is `Arc` the highest priority, Miguel?

Miguel: Yes, and also, if we can solve `Arc` we can solve others.

Alice: +1.

Wedson: And it seems a good first issue.

JT: One thing we could do is try to add a narrower version that'll work for RfL's `Arc` without necessarily being fully general.

Alice: Adrian reached out to me about arbitrary self types, and I've left a comment about that. There are parts of it that are not important for us, so those shouldn't be blocking, at least for us. So from our perspective, it seems the scope could be narrowed.

JT: We have been known to narrow the scope where we can, so that is helpful.

TC: Note also that we have a design meeting for arbitrary self types next week.

TC: Do we want to talk about `Arc` two weeks from now?

JT: Yes, and let's also be sure to talk about Alice's feedback in the arbitrary self types next week.

Alice: Since there is already work ongoing on arbitrary self types, we could go further and think about hwho we need for dynamic dispatch. There doesn't seem to be a concrete proposal fo how to move forward on that.

Josh: Could you elaborate on the dynamic dispatch issue?

Alice: The problem is that we have an `Arc<SomeStruct>`, and that's fine, but what if we want `Arc<dyn SomeTrait>`?

Wedson: There's another trait, `CoerceUnsized`.

Alice: Yes, those come in pairs.

JT: Yes, and there's some connection here with what will survive in arbitrary self types.

tmandry: Anyone know who the leading expert is on these traits? It looks like nrc wrote the original RFC.

Alice: It may be worth seeing who commented on the IRLO thread.

https://internals.rust-lang.org/t/pre-rfc-flexible-unsize-and-coerceunsize-traits/18789

JT: We should look at whether this is discussed in the arbitrary self types RFC. Looking at it now, it says that not all receivers will want to support object safety, and so it treats this orthogonally. We could stabilize that independently. But sounds like RfL needs both.

Alice: For us, dispatch from dyn is maybe the more important one.

Alice: Without dispatch from dyn, the RfL project can't use trait objects here at all.

JT: This is related to the C abstraction of a struct full of function pointers.

JT: OK, then we should prioritize `DispatchFromDyn`.

Wedson: There's intersection with file pointers in the kernel here.

Gary: We'd have to think about how arbitrary self types and `DispatchFromDyn` work together.

JT: Definitely.

Gary: If we stabilize arbitrary self types without considering dynamic dispatch, maybe doing the latter would be more difficult.

## Extra design meeting?

tmandry: To what extent are we planning extra design meetings here? It seems this discussion could require discussion of the full lang team.

TC: To perhaps build on tmandry's point, we could ask here whether we're trying to *solve* these problems or whether we want to use these meetings to *discover* these use cases and to e.g. document them and *input* to the lang (or project) design process.

tmandry: To have a productive meeting where we're actually trying to solve the problems, it seems that we need to have a full design meeting document. Perhaps, similar to what TC was saying here, we could talk first about collecting information to feed into that.

tmandry: Concrete proposal then. We work together to put together a document that explains the RfL use cases for `DispatchFromDyn`. That would feed into the larger design process.

TC: Is there someone on the RfL side who could put together a document here for the call in two weeks?

Miguel: Yes, perhaps Alice.

tmandry: Any objections to using Google Meet instead?

(None.)

tmandry: I'll generate a link then.

(The meeting ended here.)