-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
support explicit discriminant numbers on tag variants #1393
Comments
I'll look into this. Expect something in the next couple of days. |
see Issue #1397. |
Should it be legal to have both associated data and an explicit discriminant value? |
My opinion: why not? Also, the discriminant value ought to increase by 1 from the previous discriminant, just as in an enum. So: tag t { |
I'm not sure on the value of having both data and discriminant values, and even less sure on the syntax, for now I'll disallow it by not supporting the syntax for it. Also, my patch does increase by 1 when not specified just like the C enum does as it is trivial to implement. |
Addresses issue rust-lang#1393. For now disallow disr. values unless all variants use nullary contractors (i.e. "enum-like"). Disr. values are now encoded in the crate metadata, but only when it will differ from the inferred value based on the order.
Addresses issue #1393. For now disallow disr. values unless all variants use nullary contractors (i.e. "enum-like"). Disr. values are now encoded in the crate metadata, but only when it will differ from the inferred value based on the order.
@kevina - This is done? |
I'm told it's as done as it's going to get. Yay! |
organize import sections with rustfmt `group_imports`
Currently tags always use 0 ... N, where N is the number of tag variants, as the discriminant values.
This makes them useless for modeling C enums, which they are the natural analogue of. We should support a form of variant-declarator that provides a discriminant value, as (say) an uint const expression or something.
Ideal sort of example:
tag color {
red = 0xff;
blue = 0xfe;
}
It'd also be nice to be able to cast back and forth against uint values, and similar "like in C" enum tricks. But one thing at a time.
The text was updated successfully, but these errors were encountered: