The situation that sparked my question is what I’m offering as an example. Putting aside the tedious boilerplate issue, the main downsides to writing the newtype, in my case, are that:
- I would have to reimplement the functionality that
derive(Serialize, Deserialize)provides manually, I can’tderiveon a newtype because the internal types don’t already implement the traits. - In my implementation I would have to manually specify the field names for the struct I was wrapping, which would make my crate depend on every single public field associated with the struct, and therefore make it more brittle to future changes.
- If the other struct added new public fields it may not be considered a breaking change (right?) so I would now have to inspect every upgrade and see if fields were added.
- It forces traversing the vector of structs returned from
systemstatand wrapping them in my newtype. My understanding is that a simple newtype pattern on a single struct doesn’t result in any performance overhead, but it’s unclear to me if this is also true when wrapping a vector of structs, for instance. Regardless, the additional wrapping adds noise when reading the code, adding some slight cognitive overhead. - Any time I wanted to use the native functionality I would have to unwrap the new type first, with similar issues to the above.