Serde derive support?

[alok]

Being able to serialize the tree would be handy, and could be an optional feature gated behind a flag named serde or something.

[LoZack19]

I would like to open a discussion regarding whether this feature should be introduced in ego-tree. First, it should be considered that it would introduce a dependency where currently the crate has no dependencies. Also, I am interested in understanding how much of an advantage this feature would be, especially considering the domain of ego-tree usage.

[adamreichold]

First, it should be considered that it would introduce a dependency where currently the crate has no dependencies.

I think this could be an optional dependency so that the default build is still dependency free. The serde crate itself also pretty much present in any non-trivial dependency tree and hence is not a particularly "heavy" dependency, at least if we do not rely on its derive macros but implement the traits directly.

Also, I am interested in understanding how much of an advantage this feature would be, especially considering the domain of ego-tree usage.

I think as a general data structure, Serde support is a reasonable feature. It might also be good to implement it here as it could rely on the internal representation and hence be much more efficient than a third party crate do it itself (iterating the tree for serialization and rebuilding it using the public API for deserialization). But this depends on whether we can still provide a sound interface in the presence of malformed serialized data, i.e. possibly nonsensical but no undefined behaviour if possibly malicious data is deserialized into a tree.

[LoZack19]

What is the problem of using derive? How much would we benefit from a manual implementation of the Serialize and Deserialize traits?

[adamreichold]

What is the problem of using derive?

The problem is the increase in build times because Serde's proc macros need to be built before crates which rely on them can be built. This often ends up serializing a large part of the dependency tree and thereby disproportionately prolongs overall build times.

[cfvescovo]

Depending on serde isn't really an issue for us since, as @adamreichold said, a lot of crates have it in their dependency tree. In addition, we could feature-gate this

[LoZack19]

We could still manually expand the output of the derive macro, thus avoiding this problem, but then we would need to maintain our implementations of the serde traits, which could be tedious. Since Serde's API is stable, we shouldn't need to update that code too often or at all.

[LoZack19]

I am working on a PR

[cfvescovo]

We could still manually expand the output of the derive macro, thus avoiding this problem, but then we would need to maintain our implementations of the serde traits, which could be tedious. Since Serde's API is stable, we shouldn't need to update that code too often or at all.

We can just impl Serialize and impl Deserialize