Proposal for C-like nested enums to become scalar data types

[pczarn]

Implementation. Works for simple enums, but otherwise untested

CLICKME for richness

[nrc]

This is related to the various proposals for efficient inheritance, in particular #245. I would very much like a general system for nested enums (whether or not we use this as a basis for efficient inheritance) and if we do that then I would not like to see something like this which does a subset of that in a different way. However, we could (and probably should) adapt the proposal here for C-like nested enums to become scalar data.

[pczarn]

@nick29581 I don't think anything in this proposal is necessarily related to inheritance. Perhaps the word "nested" is inappropriate, these are transitively C-like enums.

[nrc]

@pczarn it is a very different use case from inheritance, but as far as data is concerned its the same. In particular #245 would allow you to a significant portion of this RFC, albeit with a different syntax.

[ghost]

Enum templates seem to fall out of the scope of this proposal, which is not good given the ubiquity of Option and Result. Also, you can't add the required attribute (required for the optimization to take place) to an enum that's defined in a library you can't change the source code of.

[huonw]

Thanks for the RFC. We discussed this in the triage meeting and decided that while it was something that might be useful, it's not something that needs to be done for 1.0, since it is backwards compatible. Furthermore, this sort of precise layout control is related to "bit data" proposals like #327 (also postponed #346) so we would like to consider these features in a unified way.

That said, it appears there is only one "real" language changes here: allowing explicit C-like discriminants in enums with data. The layout optimisations is actually something we can do implicitly now since the layout of enums is undefined, that is to say, if we have enum Foo { X, Y, Z }, the compiler is with its rights to represent Option<Foo> as a single byte.

If you were to tune your patch to just do this (i.e. no language changes or external user control, for now), it may be landed and would not require an RFC. However, it is relatively complicated trans code, so you may wish to open a discuss post and solicit feedback from people like @luqmana and @nikomatsakis before putting effort into the code.

(cc #347)