Jelte Fennema-Nio

Hey @cbreeden, I changed your comment at the top a bit for an easy checklist. I hope you're fine with that. Display is now implemented on master for newtypes btw.

I have a `deref` branch at the moment (not merged because I haven't made the docs yet), but it is quite different from shrinkwraprs. It will just forward the operations...

I've just released v0.10.0 with `Deref` and `DerefMut` support. Example usage and generated code can be found here: https://jeltef.github.io/derive_more/derive_more/deref.html https://jeltef.github.io/derive_more/derive_more/deref_mut.html I think those links should show the difference in usage...

Yes, that sounds like a good idea. On Wed, 11 Sep 2019, 02:19 Bobby Reynolds, wrote: > @AGausmann for structs with multiple > fields, I think it would make sense...

@AGausmann on one hand that makes sense, but we already do that for the `display` style attributes. So I think it's okay to have them as top level ones to...

Derives for any standard library traits fit in this library, so also for Error. So I'm definitely open to a PR. I'm not entirely sure how you would want to...

You should be able to use #[derive(DebugCustom)] for that.

Is this for structs or enum derives? Because if it's for structs I think a nicer solution would be to generate code to generate code like this (untested) instead of...

Turns out `thiserror` does it using this way: https://github.com/dtolnay/thiserror/blob/master/src/aserror.rs Which means that to replicate the same runtime support is needed in `derive_more`. Which will mean some restructuring of the crate...

Can you show a bit more usage of this `FromStr` implementation? And also the definition of the `MyError` type.