RFC: enum discriminant ought to be smaller

[nikomatsakis]

We use int not i32. This is both wasteful and not compatible with C, where enums are always C integers (i32). We ought to fix this but #1645 makes it hard to do in general.

However, we could make this work in the special case of C-like enums, by changing trans::type_of_tag() to represent such tags as ints.

[kevina]

Note, C integers are not always i32, the C standard allows them to be different sizes depending on the possible values they can take, but making them i32 will cover most of the cases.

Ideally, the size of the discriminant should be allowed to change based on the size of the values it can take, just like it is done in C, so that they can take values outside of the range of i32.

[nikomatsakis]

@kevina thanks for the clarification. Yes, we should adapt C-like enum representation to match precisely what C compilers would do (or as close as we can get). I guess the key point is that C-like enums can be represented differently from enums with data with relative ease. To what extent is the size of integer used for an enum defined in the C spec? Is it all impl. dependent?

[kevina]

@nikomatsakis yes its mostly impl. dependent. See http://stackoverflow.com/questions/366017/what-is-the-size-of-an-enum-in-c

[graydon]

This has more to do with us not being LP64 I imagine. Which is to say: our ints are bigger than those in C, on a lot of 64 bit platforms. But we don't have long (and I don't want it), so we wound up effectively going ILP64, which is rarer.

Not really sure what to do about it. Comments welcome. Being LP64 -- that is, demoting our int down to the same size whatever our platform's C int is -- would make the C interop story a bit, certainly. So it might be wise. See http://www.viva64.com/media/images/content/a/size_t_and_ptrdiff_t/image2.png for a rough picture of the popularity of each.

Something about keeping 32-bit integers alive-by-accident longer than necessary just rubs me the wrong way, I guess. It's 2012. I imagine I can buy 64-bit-word phones by now.

[pcwalton]

This sounds like an RFC. I guess I slightly favor the current system; "enum is always an int" seems like a simpler rule and if the enum has to contain anything it'll probably be 64 bit aligned anyhow.

[nikomatsakis]

I could see an argument for representing C-like enums as C integers (for compatibility).

[graydon]

see also #1704 and #1271

[jld]

I've been working on making enums smaller. I think what @nikomatsakis and I have converged on is: enum discriminants should be as small as (efficiently) possible, with the option to specify a specific size or C enum compatibility, and a lint warning (like what we already have for Rust's int) if enums without a C-friendly hint are used for FFI.

[thestinger]

There isn't actually a defined ABI for C enums, the size can vary per declaration. There's a -fshort-enums flag for gcc but it's default on some platforms like AAPCS-based ARM.

C libraries should really be using static const (or #define) in headers if they expect to support bindings and be compiler independent but that's often not the case....

[jld]

I think it's true (or at least sufficiently true for our purposes) that, given a C enum and given an ABI, there exists an integer type to be used for it. It might vary per enum, and it might not be the same on an AMD64-SysV-based platform and an APCS-based platform, but this is already true for data representations in general. So, a "represent this like C" flag could work.

The other thing going on here is Rust's existing knowledge of C representations, which is currently in core::libc as typedefs rather than in the compiler. This makes things more interesting, because any enum annotation that would allow referencing them (“this enum should be represented as a C int”) needs to either be real syntax so it can contain a type expression, or else (e.g., if it's done with attributes) call into name resolution in a way that I don't think anything else does, or maybe language items could work. It also suggests that the knowledge of C enum layout should be in core::libc, and that probably needs at least 12 typedefs ({8, 16, 32, 64} × {fits in unsigned, fits in signed, fits in either}), and I don't know what else would need it.

The other other thing is that I don't know how much of this is actually needed, at least in the short term.

[thestinger]

@jld: there isn't an enum ABI shared between compilers on the platform though - there's no way to represent one like C, you can just represent it like a specific C compiler with specific compiler flags.

#include <stdio.h>

enum foo { A, B };
enum bar { C = 256, D, E };
enum baz { F = 8796093022208, G };

int main() {
  printf("%zu\n", sizeof(enum foo));
  printf("%zu\n", sizeof(enum bar));
  printf("%zu\n", sizeof(enum baz));
  return 0;
}

clang/gcc on x86_64 without flags:

4
4
8

with -fshort-enums (default on some platforms)

1
2
8

If Rust represented them with the smallest size possible, it would be compatible with -fshort-enums everywhere (assuming the compiler supports it and implements it like gcc).

[jld]

Right, but you can't (in general) link C code compiled with -fshort-enums and -fno-short-enums, because they'll disagree on sizes. GCC has other ABI-breaking flags like that, and the documentation warns about it. Rust already has to decide what C ABI it's interoperating with; how are enums different?

[pcwalton]

I don't believe this is backwards incompatible, renominating.

[graydon]

just a bug, removing milestone/nomination.