From 3dc89697236617b200126051c303093a63e2a021 Mon Sep 17 00:00:00 2001 From: Havvy Date: Tue, 5 Dec 2017 14:16:43 -0800 Subject: [PATCH] Rename C-like enums to field-less enums --- src/casts.md | 2 +- src/other-reprs.md | 22 +++++++++++----------- src/repr-rust.md | 2 +- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/src/casts.md b/src/casts.md index 31b7858..46c9975 100644 --- a/src/casts.md +++ b/src/casts.md @@ -28,7 +28,7 @@ primitive: * `*T as integer` * `integer as *T` * `number as number` - * `C-like-enum as integer` + * `field-less enum as integer` * `bool as integer` * `char as integer` * `u8 as char` diff --git a/src/other-reprs.md b/src/other-reprs.md index 697420a..a2ce433 100644 --- a/src/other-reprs.md +++ b/src/other-reprs.md @@ -23,8 +23,8 @@ passed through the FFI boundary. C, and is explicitly contrary to the behavior of an empty type in C++, which still consumes a byte of space. -* DST pointers (fat pointers), tuples, and enums with data (that is, non-C-like - enums) are not a concept in C, and as such are never FFI-safe. +* DST pointers (fat pointers), tuples, and enums with fields are not a concept + in C, and as such are never FFI-safe. * As an exception to the rule on enum with data, `Option<&T>` is FFI-safe if `*const T` is FFI-safe, and they have the same @@ -42,7 +42,7 @@ binary interface (ABI). Note that enum representation in C is implementation defined, so this is really a "best guess". In particular, this may be incorrect when the C code of interest is compiled with certain flags. -* "C-like" enums with `repr(C)` or `repr(u*)` still may not be set to an +* Field-less enums with `repr(C)` or `repr(u*)` still may not be set to an integer value without a corresponding variant, even though this is permitted behavior in C or C++. It is undefined behavior to (unsafely) construct an instance of an enum that does not match one of its @@ -53,19 +53,19 @@ compiled as normal.) # repr(u*), repr(i*) -These specify the size to make a C-like enum. If the discriminant overflows the -integer it has to fit in, it will produce a compile-time error. You can manually -ask Rust to allow this by setting the overflowing element to explicitly be 0. -However Rust will not allow you to create an enum where two variants have the -same discriminant. +These specify the size to make a field-less enum. If the discriminant overflows +the integer it has to fit in, it will produce a compile-time error. You can +manually ask Rust to allow this by setting the overflowing element to explicitly +be 0. However Rust will not allow you to create an enum where two variants have +the same discriminant. -The term "C-like enum" only means that the enum doesn't have data in any -of its variants. A C-like enum without a `repr(u*)` or `repr(C)` is +The term "field-less enum" only means that the enum doesn't have data in any +of its variants. A field-less enum without a `repr(u*)` or `repr(C)` is still a Rust native type, and does not have a stable ABI representation. Adding a `repr` causes it to be treated exactly like the specified integer size for ABI purposes. -A non-C-like enum is a Rust type with no guaranteed ABI (even if the +Any enum with fields is a Rust type with no guaranteed ABI (even if the only data is `PhantomData` or something else with zero size). Adding an explicit `repr` to an enum suppresses the null-pointer diff --git a/src/repr-rust.md b/src/repr-rust.md index a903466..c975090 100644 --- a/src/repr-rust.md +++ b/src/repr-rust.md @@ -21,7 +21,7 @@ Rust gives you the following ways to lay out composite data: * arrays (homogeneous product types) * enums (named sum types -- tagged unions) -An enum is said to be *C-like* if none of its variants have associated data. +An enum is said to be *field-less* if none of its variants have associated data. Composite structures will have an alignment equal to the maximum of their fields' alignment. Rust will consequently insert padding where