-
Notifications
You must be signed in to change notification settings - Fork 8
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
Feature Request: Explicit names and values for enum variants #9
Comments
For this use case, what would be the benefit in using this library at all? You are able to write: #[repr(u8)]
pub enum Freqency {
TwoHz = 0,
OneHz,
HalfHz
} in normal Rust, and |
There is the step feature which Im intressted in using. It's for a library and I want to keep things as open and accessable as possible. Plus this library implements a lot of arithmetical operations which is great for creating display patterns in a safe inbounds way. |
Hmm, ok. I don't think I want to support enums with holes, it feels out of scope, but I can definitely implement custom enum variant names. |
Thanks! How will the syntax look? And how will the range be set? |
I'm thinking you will just write out enum variants like in a regular Rust enum. The range will be set implicitly by the range of the values of the enum (erroring if there are holes). |
Like so: bounded_integer! {
#[repr(u8)]
enum Type {
Variant0,
Variant1
}
} and so: bounded_integer! {
#[repr(u8)]
enum Type {
Variant0 = 21,
Variant1 = 22
}
} ? And is the error a compile time error ? |
I'm not sure about the first one, since no starting value is explicitly specified - I might require |
Like the title says, allowing for explicit naming and values.
For explicit naming it has some drawbacks as to doing it the old and easy way:
But the consumer has to work with values such as
Freqency::Z0
andFreqency::P1
which in some cases is not descriptive enough. I might want to name the variants in this way:In this example I have the enum variants sent to a circuit with hardcoded values via an i2c interface.
If explicit naming is implemented we lose the ability to set the range of the bounded enum so explicit values needs to be implemented with it.
With explicit values there is the possabilities that the consumer of this library makes "holes" in the bounded range.
If we for some reason happends to find ourself in one of the holes (possible with the
step
trait) we can treat the hole as an out of bounds exception.The text was updated successfully, but these errors were encountered: