derive_more
derive_more copied to clipboard
JelteF
Some more derive(Trait) options
Currently, when one uses a top-level `display` attribute for the `Display` derive on an `enum`, it switches to an affix mode that defines the `enum`'s overall format and expects, at...
The #[from(ignore)] syntax could be helpful in other traits as well. The ops such as Add are the case I specifically was looking for, but it's not hard to imagine...
`newtype_derive` seems to allow this, but appears to be unmaintained. Allow specifying `#[From(usize)]` for a `u32` newtype. The conversion would just use `as` to do the conversion. My use case...
Hi! I believe that: ```rust #[derive(AsRef)] struct Foo { t:i32 } ``` should generate identity `AsRef` impl in addition to what it generates now: ```rust impl AsRef for Foo {...
Currently you can't just write ```rust #[derive(Debug, Display, Error)] pub enum MyError { #[display(fmt = "something failed")] Failed { #[error(source)] source: Box
`std::iter::Step` is implemented for all integer types. It is useful to derive `Step` in newtypes that are intended to have ranges, e.g. a coordinate class. It is a nightly feature...
There's not really a reason to derive from for `()` for variants without fields. It's somewhat unexpected and results in the problems described here in #105. Let's remove this in...
We have a lot of instances of this pattern: ```rust #[derive(Debug, PartialEq, Eq, Hash, Clone, Copy, DieselNewType, Serialize, Deserialize, From, Into, Display)] pub struct Foo(Uuid); impl FromStr for Foo {...
Love the library, thanks for your work. Wanted to point out a small bug: I have a struct like: ```rust #[allow(clippy::too_many_arguments)] #[derive(Constructor, Clone)] pub struct SomeStruct { pub field1: String,...
