Conversation
Manishearth
left a comment
Manishearth
left a comment
There was a problem hiding this comment.
In favor of the general implementation. I think the way you handle method docs/pub/etc is clever.
This is exactly along the lines as what I was envisioning for transparent casts for a long time, and is significantly better than my imagined level of complexity.
|
Thanks; if this direction looks good to you then I'll clean up this PR and get it ready for merging. |
| /// Implements [`ZeroFrom`](crate::ZeroFrom) on a transparent type | ||
| /// from a reference to the inner type. | ||
| /// | ||
| /// Also supports creating concrete functions. |
There was a problem hiding this comment.
nit:
| /// Also supports creating concrete functions. | |
| /// Also supports adding concrete conversion functions between various reference types. |
| #[repr(transparent)] | ||
| $(#[$meta:meta])* |
There was a problem hiding this comment.
this is sensitive to attribute ordering, which it shouldn't be
| $vis_box:vis fn $fn_box:ident(Box<$type_box:ty>) -> Box<Self>; | ||
| )? | ||
| $( | ||
| @rc |
There was a problem hiding this comment.
let's try to keep custom syntax to a minimum. it should suffice to match on the argument
| #[repr(transparent)] | ||
| /// hello world | ||
| #[derive(Debug)] | ||
| pub(crate) struct Foo([u8; 3]); |
There was a problem hiding this comment.
I don't like type declarations living inside macro invocations. From a call site it's not known that this code is passed through without modifications, the macro could do anything to it (change the repr, add fields, wrap fields, etc).
3 participants
Latest attempt at #7607
Looking for feedback on the general approach, and then on the concrete implementation.
Changelog
zerofrom: Adds macro to derive ZeroFrom and concrete functions for repr(transparent) conversions
zerofrom::transparent!