ABI Stability

[kainino0x]

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-breaking on this yet.

Off the top of my head:

• Figure out how to test this (https://lvc.github.io/abi-compliance-checker/ ?)
• Document what the standard build configuration is for ABI stability. For example here are some things that may affect the ABI:
  • WGPU_NULLABLE (Nullability attributes need some love #190)
  • WGPU_OBJECT_ATTRIBUTE (No way to refine types/enums/functions for Swift #179)
• Are there any C language features that are never ABI-stabilizable? Like enum sizes?
• Make sure everything in the ABI works between C and C++ (#ifdef __cplusplus, etc.)
  • For example this includes things like stdbool.h bool which is incompatible with C++ bool. We don't use this anymore. (Issues with C / C++ bool type. #84)

[kainino0x]

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