This is somewhat related to #4031, but I would like full type support for enums, mainly named field variants
enum Birthday {
Custom(String),
// ? currently unsupported
Date {
day: u8,
month: u8,
year: Option<u16>
}
}
as well as tuple variants
enum Birthday {
Date(u8, u8, Option<u16>),
...
}
both currently error with must be a unit variant or a newtype variant
You can get around this by creating a struct and wrapping it as a newtype variant, but for types that will only ever be used as a single enum variant, that's not ideal.
In my testing manually implementing the derive macro, sats seems to support named field variants just fine, and with only that change you can deploy to maincloud without issue, reads and writes all work, only the module codegen step currently fails.
I haven't tested tuple variants, as I don't personally need them, they're just listed here to complete the type support.
Requested by @tyrantlink via the SpacetimeDB site.
This is somewhat related to #4031, but I would like full type support for enums, mainly named field variants
as well as tuple variants
both currently error with
must be a unit variant or a newtype variantYou can get around this by creating a struct and wrapping it as a newtype variant, but for types that will only ever be used as a single enum variant, that's not ideal.
In my testing manually implementing the derive macro, sats seems to support named field variants just fine, and with only that change you can deploy to maincloud without issue, reads and writes all work, only the module codegen step currently fails.
I haven't tested tuple variants, as I don't personally need them, they're just listed here to complete the type support.
Requested by @tyrantlink via the SpacetimeDB site.