Investigate `miniconf::{Array, Option}` wrapper struct usability

quartiq / miniconf

Rust serialize/deserialize/access reflection for trees (no_std, no alloc)

MIT License

23 stars 2 forks source link

Investigate `miniconf::{Array, Option}` wrapper struct usability #106

Closed ryan-summers closed 1 year ago

ryan-summers commented 1 year ago

Investigate the usability of miniconf::{Option, Array} as opposed to additional #[miniconf(defer-further)] or something similar.

Current arguments:

The current API (Array and Option) allows for easier muxing and nesting of array types
The attribute-based approach removes the wrapper types, which enables the outer settings struct to implement all kinds of derived traits (e.g. defmt)

ryan-summers commented 1 year ago

One finding noted by @jordens is that it is not possible #[derive(Serialize, Deserialize)] on settings structures that contain the wrapper types

jordens commented 1 year ago

Small correction: #[derive(Serialize, Deserialize)] is in fact available and implemented for Option but for Array it's blocked because of the limitation of the inner impls to 32 elements. IMO this is the only downside of the wrapper types that I can see so far. Usability seems very good.

jordens commented 1 year ago

For Array one could consider use serde_big_array with additional bounds on T (with e.g. derive_where). Having used these in anger and over a good range of applications has been a good experience. Let's close this and open issues when and if they arise.