{"id":50807,"date":"2026-01-23T19:28:42","date_gmt":"2026-01-24T00:28:42","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=50807"},"modified":"2026-01-26T12:16:25","modified_gmt":"2026-01-26T17:16:25","slug":"improving-the-usability-of-c-libraries-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/01\/23\/improving-the-usability-of-c-libraries-in-swift\/","title":{"rendered":"Improving the Usability of C Libraries in Swift"},"content":{"rendered":"

Doug Gregor<\/a>:<\/p>\n

\n

The Swift code above has a very “C” feel to it. It has global function calls with prefixed names like wgpuInstanceCreateSurface<\/code> and global integer constants like WGPUStatus_Error<\/code>. It pervasively uses unsafe pointers, some of which are managed with explicit reference counting, where the user provides calls to wpuXYZAddRef<\/code> and wgpuXYZRelease<\/code> functions. It works, but it doesn’t feel like Swift, and inherits various safety problems of C.<\/p>\n

Fortunately, we can improve this situation, providing a safer and more ergonomic interface to WebGPU from Swift that feels like it belongs in Swift. More importantly, we can do so without changing the WebGPU implementation: Swift provides a suite of annotations that you can apply to C headers to improve the way in which the C APIs are expressed in Swift. These annotations describe common conventions in C that match up with Swift constructs, projecting a more Swift-friendly interface on top of the C code.<\/p>\n

[…]<\/p>\n

The problem of needing to layer information on top of existing C headers is not a new one. As noted earlier, Swift relies on a Clang feature called API notes<\/a> to let us express this same information in a separate file, so we don’t have to edit the header.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n