Rust Serialization in Nunavut vs. Proc Macros

Applications & Usage
1

I brought it up in the weekly call, I was mostly just trying to make sure people knew what needed to be implemented/the constraints that Rust adds. (Apologies for not being more prepared on explaining this during the call, I wasn’t even properly sure of what I was trying to say).

Again, I’m not particularly opposed to either implementation, but in my conversations with @alexander_huebener that is the preferred direction. I don’t think there are really any major technical reasons that make either way a objectively better, it’s mostly just organizational preference, IMO doing it with macros is more useful for Alexander’s thesis and I would rather have serialization working in some form than wait around for the preferred organizational solution (I don’t have time to implement serialization in the near future).

The main point I tried to get across is that at a minimum there needs to exist an external crate (it can’t be generated per-namespace within the support tooling that nunavut already has). And this external crate (may as well call it nunavut-traits or something) must at least have the following trait definition.

trait NunavutSerializable {
    fn serialize(&self, buffer: &mut [u8]) -> Result<(), SerializationError> {}
    fn deserialize(&self, buffer: &mut [u8]) -> Result<(), SerializationError> {}
}

The same trait can’t be multiply-defined, so if this trait was defined in the support files (as you could with a C++ header I believe), you would just get a bunch of different trait types in different namespaces, which basically eliminates the use of using a trait and any of the generics support rust has.

The main point is that there already exists a disconnect between nunavut and the Rust side of things (that is completely independent from the uavcan.rs implementation), and that this extra crate (could be called nunavut_traits or something) would be the logical place to put Rust serialization macros if we went that route. (It would also make testing a bit easier because we could just integrate testing into the crate instead of jerry-rigging something into the nunavut infrastructure)

I don’t even know if this is an important point to make or not I just brought it up during the call, and got flustered because I wasn’t prepared to explain it, and felt I should explain it properly.

2

Nunavut does not generate support code per-namespace, it is always standalone. The use case you described is common across all target languages we have on the roadmap; for example, Python code relies on abstract classes that generated ones inherit from.

3

:man_facepalming:

Of course, and that explains the disconnect I had when I was trying to explain during the call. I don’t know why I thought that - I did do a bunch of the intro C serialization work.

With that context there’s even less to differentiate between rust macros and using templates then, because it all ends up working the same in the test suite anyways.

1 Like