superstruct
superstruct copied to clipboard
sigp
Rust library for versioned data types
"Features" are components of variants which can be enabled, disabled and reordered at compile-time based on a "variant & feature ordering" WIP with @macladson.
This compiles while ignoring the second attribute: ```rust #[superstruct(variants(A, B))] #[superstruct(variants(C, D))] struct MyThing; ``` We should reject it, but it's not clear how to do this. See https://github.com/sigp/superstruct/pull/38 and...
At the moment `superstruct` accepts `specific_variant_attributes` for variants that do not exist. We should raise an error in this case.
Currently superstruct uses a `fn` type for the closure passed to a mapping macro, meaning that variables can't be captured. The reason we use `fn` is that it's a reliable...
Presently `superstruct` will accept code like: ```rust #[superstruct(no_enum, variants(A, B))] #[derive(Serialize, Deserialize)] pub struct Thing { ... } ``` The `derive(Serialize, Deserialize)` doesn't make sense here because there's no top-level...
Presently the mutable getters on `RefMut` require that the `self` parameter has the same lifetime as the inner reference. So for a type like this `Message`, we generate getters as...
Occasionally it's useful to be able to convert a struct into one of its fields without cloning, and without destructuring. We could generate methods like: ```rust pub fn into_field(self) ->...
Unlike regular fields, `superstruct`'s mutable getters don't lend themselves to disjoint mutable borrows, i.e. borrowing `field1` and `field2` simultaneously, where at least one of the borrows is mutable. This can...