Using enums in a C ABI can make it harder for non-C languages to cooperate, as they have to find out the enum bitwidth when implementing the ABI. Granted, the enum bitwidth is normally set by the platform ABI, but people still have to find that information and perhaps write platform-specific code to handle it correctly. Using explicitly-sized ints (such as int32_t etc.) instead of enum-typed struct fields would avoid that issue.
FTR, x86-64, which I assume is the dominant platform for DLPack, mandates 32-bit integers for enums both on the "SysV ABI" (used by Linux, macOS...) and Windows. So, doing this change while minimizing potential breakage would probably require adopting int32_t fields in structs where enum fields where used.
(this does not forbid the existence of an enum declaration in the C header, btw; just in struct fields)
Using enums in a C ABI can make it harder for non-C languages to cooperate, as they have to find out the enum bitwidth when implementing the ABI. Granted, the enum bitwidth is normally set by the platform ABI, but people still have to find that information and perhaps write platform-specific code to handle it correctly. Using explicitly-sized ints (such as
int32_tetc.) instead ofenum-typed struct fields would avoid that issue.FTR, x86-64, which I assume is the dominant platform for DLPack, mandates 32-bit integers for enums both on the "SysV ABI" (used by Linux, macOS...) and Windows. So, doing this change while minimizing potential breakage would probably require adopting
int32_tfields in structs whereenumfields where used.(this does not forbid the existence of an
enumdeclaration in the C header, btw; just in struct fields)