# Rust Serialization in Nunavut vs. Proc Macros

**URL:** <https://forum.opencyphal.org/t/rust-serialization-in-nunavut-vs-proc-macros/1454>\
**Category:** Applications & Usage\
**Created:** [September 22, 2021, 8:26pm UTC](https://forum.opencyphal.org/t/rust-serialization-in-nunavut-vs-proc-macros/1454 "2021-09-22T20:26:07Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![david.lenfesty](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/david.lenfesty/32/488_2.png) [@david.lenfesty](https://forum.opencyphal.org/u/david.lenfesty)\
**Post date:** [September 22, 2021, 8:26pm UTC](https://forum.opencyphal.org/t/rust-serialization-in-nunavut-vs-proc-macros/1454/1 "2021-09-22T20:26:07Z")

</div>

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.

```rust
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.

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [September 23, 2021, 9:38am UTC](https://forum.opencyphal.org/t/rust-serialization-in-nunavut-vs-proc-macros/1454/2 "2021-09-23T09:38:11Z")

</div>

> [@david.lenfesty](#):
>
> 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)

> [@david.lenfesty](#):
>
> 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

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.

---

<div class="post-metadata">

**Author:** ![david.lenfesty](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/david.lenfesty/32/488_2.png) [@david.lenfesty](https://forum.opencyphal.org/u/david.lenfesty)\
**Post date:** [September 23, 2021, 3:45pm UTC](https://forum.opencyphal.org/t/rust-serialization-in-nunavut-vs-proc-macros/1454/3 "2021-09-23T15:45:52Z")

</div>

🤦‍♂️

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.