-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deref
and DerefMut
for enums
#388
Comments
For the cases you describe I agree it should be possible (at least the first one, the second one might be harder). So no technical reason, just no-one implemented it yet. |
+1 for this. My use case could easily be derived: enum Compression {
Stored(u32),
Zlib(u32),
LZMA1(u32),
}
impl Deref for Compression {
type Target = u32;
fn deref(&self) -> &Self::Target {
match self {
Self::Stored(size) | Self::Zlib(size) | Self::LZMA1(size) => size,
}
}
}
impl DerefMut for Compression {
fn deref_mut(&mut self) -> &mut Self::Target {
match self {
Self::Stored(size) | Self::Zlib(size) | Self::LZMA1(size) => size,
}
}
} |
I had a short session where I tried to implement this feature. I came across a few speed bumps which changed my opinion a little. 1. We can only support enums with "unnamed" data fieldsWe already know one condition is that the data fields across the input enum must be consistent in some way. Additionally, unless I'm missing something, we can't support the "named fields" enum data type. Even if data were consistent, with named fields it's not clear what the enum MyEnum {
Variant1 {
named_field1: u8,
named_field2: bool,
},
Variant2 {
named_field1: u8,
named_field2: bool,
},
} These variants with named field data are not proper types, so there is no clear type to return in these cases. I guess we could annotate a named field in each variant with So I guess this means that we can only support enums with unnamed fields as data. 2. We can only support unnamed fields with 1 tuple fieldEven if we restrict support to enums with unnamed fields style data, there's still an issue if the data contains more than one field. For example: enum MyEnum {
Variant1(u8, bool),
Variant2(u8, bool),
} What would the So additionally we would need to restrict support for deriving SummarySo overall deriving |
@BenLeadbetter I think you're making this more complicated than necessary. We can use the same approach that we use for structs with multiple fields here: Adding a // You can specify the field you want to derive `Deref` for.
#[derive(Deref)]
struct CoolVec {
cool: bool,
#[deref]
vec: Vec<i32>,
} So your examples with enums should then look like this, if you want to to create a Deref derive for #[derive(Deref)]
enum MyEnum {
Variant1 {
#[deref]
named_field1: u8,
named_field2: bool,
},
Variant2 {
#[deref]
named_field1: u8,
named_field2: bool,
},
}
enum MyEnum {
Variant1(#[deref] u8, bool),
Variant2(#[deref] u8, bool),
} |
Is there a technical reason not to support
Deref
andDerefMut
for enum input types? Seems to me like this would work pretty idiomatically so long as the different variants all supported a consistent target.For example:
The text was updated successfully, but these errors were encountered: