Repository navigation
ABI Stability #282
Description
Activity
Apr 11 meeting:
- KN: re earlier discussion — is there actually any reason to have the non-function-pointer function definitions in the header…?
- yes, static linking, global loading, GL/vulkan do it, etc.
- KN: How can we figure out if there’s anything we need to consider for ABI stability before stabilizing the API? Like C constructs we should avoid, etc.?
- Or should we just make (attempted) ABI stability part of 1.0 so we don’t have to worry about it?
- (discussion)
- CF: Don’t think we should, bigger problems to deal with
- No, not worth doing now. Probably won’t need to break API to do ABI stability but if we do we can deal with it, we’ll just do 2.0 or whatever. Mark non-breaking.
- Tentative - AE/KN also to check with other people who want this
- KN: re earlier discussion — is there actually any reason to have the non-function-pointer function definitions in the header…?
Just a note about
_Boolbecause for some reason I couldn't find any record of the discussion I know we had:The reason we don't use
_Boolis because it doesn't exist in C++. If we usedboolfromstdbool.h, it should compile/link fine, but this would result in C using_Bool(ignoring pre-C99) and C++ using itsbool._Booldoesn't exist in C++ so there's no way for C++ code to use a C ABI that contains_Bool. In practice it almost certainly works everywhere we care about, but the only way to know would be to define a list of target C and C++ ABIs and read the specification for each and make sure they match between C and C++.- https://stackoverflow.com/a/16974736 says formally they aren't required to match
- A few answers on https://stackoverflow.com/questions/40020423/getting-bool-from-c-to-c-and-back talk about the answer in specific ABIs
Tracking issue for ABI stability.
Actually stabilizing the ABI is going to come after stabilizing the API ("1.0"), but there's a chance of ABI stability problems that require us to make API changes (like stdbool did). So I'm not putting
non-breakingon this yet.Off the top of my head:
WGPU_NULLABLE(Nullability attributes need some love #190)WGPU_OBJECT_ATTRIBUTE(No way to refine types/enums/functions for Swift #179)#ifdef __cplusplus, etc.)stdbool.hboolwhich is incompatible with C++bool. We don't use this anymore. (Issues with C / C++ bool type. #84)