Reword/reorder the bit about enums without backing types to make it obvious that new code shouldn't do this.
PiperOrigin-RevId: 678817890
Change-Id: Ic4c0597a3696e93b517a146ec4e0a2f738a2fdd0
diff --git a/api-guidelines/ndk.md b/api-guidelines/ndk.md
index 2cedfdd..bfad741 100644
--- a/api-guidelines/ndk.md
+++ b/api-guidelines/ndk.md
@@ -450,17 +450,19 @@
3. **If libc has an existing preference, use that instead** (eg, use `pid_t` if
you’re taking a process ID)
-4. **Use `int32_t` or `int64_t` for enum params/returns that do not have an
- explicit backing type.**
+4. **Use `int32_t` or `int64_t` for legacy enum params/returns that do not have
+ an explicit backing type.**
- - The backing size of an enum is up to the compiler. As such, even if a
- parameter or return value represents an enum use instead a fixed-type
- like `int32_t`.
- New enums should define an explicit backing type for the enum to avoid
this requirement.
- Old enums can adopt the old integer argument type as their backing type.
New functions are then encouraged to use the enum directly. Existing
- APIs are not encouraged to update their signatures, but may do so.
+ APIs may update their signatures, but are not required to do so (doing
+ so is especially helpful for Rust callers).
+ - When an enum has no backing type and one cannot be added, the backing
+ type of an enum is up to the compiler. In those cases, even if a
+ parameter or return value represents an enum, use instead a fixed-type
+ like `int32_t`.
5. **Avoid `off_t`.**
