API Workshop #3 (Rust) [2025-04-14]

[darkwisebear]

Participants

@qor-lb
@MarkSchmitt
@simon-acc
@elBoberido
@darkwisebear

Agenda

• Discuss further work mode (WS?)
• Merge sample PR
• Event API

Minutes

Merge sample PR

Discussion on Reloc vs Unpin traits

• It is agreed that Unpin is not enough (maybe it's a supertrait?). See doc on Reloc for further info
• We will merge the PR "as-is" (squash into one commit per WS). Open discussions (assoc type vs. generic on sample traits / naming of Runtime) will be turned into Github issues. @darkwisebear
• @elBoberido does some research on use cases where associated types take advantage over generics on traits
• @darkwisebear to send a mail / GH comment when PR has been tidied up

Work mode / workshop / 0.5 timeline

• Current work mode is seen as productive so far
• Workshop considered meaningful after some more online meetings to collect topics worth discussing (time line: ~end of May / beginning of June). Suggested date: June 2nd/3rd. Suggestion is to have it in FIZ Munich. Until then we will block Tue 22nd Apr every 2 weeks.

Event API / interface grouping

• How would we incorporate the Lola interface grouping into the API? Do we want that?

Side discussion / higher level discussion

• Would we want to group events/methods using interfaces on application level?
• If interfaces exist: What consequences do changes have?
  --> Question on COM level: What do we want in the long run, how do we go about 0.5?

[elBoberido]

@darkwisebear @qor-lb @MarkSchmitt @simon-acc

Regarding the GAT. A better example than what I showed the last time is when you want to be generic over another generic type, e.g. Rc and Arc.

This is copied from https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push/

trait PointerFamily {
    type Pointer<T>: Deref<Target = T>;

    fn new<T>(value: T) -> Self::Pointer<T>;
}

struct ArcFamily;
struct RcFamily;

impl PointerFamily for ArcFamily {
    type Pointer<T> = Arc<T>;
    ...
}
impl PointerFamily for RcFamily {
    type Pointer<T> = Rc<T>;
    ...
}

struct MyStruct<P: PointerFamily> {
    pointer: P::Pointer<String>,
}

Here, you cannot just pass a Rc or Arc as generic parameter but have to do a detour via a struct that implements the trait for the given pointer type. Does this clarify the use case enough? If not, we can talk further about this in the meeting later today.

In our case with the sample, it might also be helpful when we do not want to define whether a sample needs to be shareable between threads or if we leave it up to the user. With GAT's this would be possible since one could define this in a custom runtime/adapter.

In fact, we use the same mechanism in iceoryx2 to enable a customization of the messaging pattern. One generic parameter defines all the implementations of some traits that are required to have a publish-subscribe messaging pattern and in theory, we could create a publish-subscribe service based on LoLa.