# \[Accepted\] SE-0495: C-compatible functions and enums **URL:** \ **Category:** Announcements\ **Created:** [October 23, 2025, 6:27pm UTC](https://forums.swift.org/t/accepted-se-0495-c-compatible-functions-and-enums/82833 "2025-10-23T18:27:50Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 23, 2025, 6:27pm UTC](https://forums.swift.org/t/accepted-se-0495-c-compatible-functions-and-enums/82833/1 "2025-10-23T18:27:50Z")
Hey all, The review of [SE-0495: C-compatible functions and enums](https://forums.swift.org/t/se-0495-c-compatible-functions-and-enums/82365) ended on October 9th (with a short extension to discuss [a late modification](https://forums.swift.org/t/se-0495-c-compatible-functions-and-enums/82365/36)). Feedback on this proposal was generally positive. There were a few questions raised on the thread worth mentioning: - Q: If you have C `size_t` it comes in as `Int` for “system” headers via Clang, but `Int` would normally bridge to `ptrdiff_t` . What type do I need to use on the Swift side to implement a function that takes/returns a `size_t` in a C header? - Q: Is `@c` too terse/unspecific? - Q: How will we handle types that are not uniformly supported by compilers / C language versions? The Language Steering Group has decided to **accept this proposal**. Thanks to everybody who participated in the review! —Steve Canon, review manager ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [October 23, 2025, 9:14pm UTC](https://forums.swift.org/t/accepted-se-0495-c-compatible-functions-and-enums/82833/2 "2025-10-23T21:14:58Z")
> [@scanon](#): > > Q: If you have C `size_t` it comes in as `Int` for “system” headers via Clang, but `Int` would normally bridge to `ptrdiff_t` . What type do I need to use on the Swift side to implement a function that takes/returns a `size_t` in a C header? > > A: Whatever type the C function imports as (`Int` in this case). This is not correct. Swift can map size\_t to Int on import because they have the same ABI, but the generated header goes beyond ABI into API, where signedness matters (not just for diagnostics, but also for promotion). Fortunately, the proposal does not claim this; it maps _UInt_ to size\_t and Int to ptrdiff\_t. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [October 23, 2025, 9:20pm UTC](https://forums.swift.org/t/accepted-se-0495-c-compatible-functions-and-enums/82833/3 "2025-10-23T21:20:26Z")
What you’re are describing is correct for a @c function that isn’t implementing a function declared in a C header, but this question was about what happens for a marked implementation of a function with a C header prototype. (I.e. it is the _importer’s_ view of the type mapping that determines if an implementation matches a C header’s prototype.) ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [October 24, 2025, 3:05am UTC](https://forums.swift.org/t/accepted-se-0495-c-compatible-functions-and-enums/82833/4 "2025-10-24T03:05:42Z")
Thanks. I guess it’s ambiguous what fclout was asking about here: > [@SE-0495: C-compatible functions and enums](https://forums.swift.org/t/se-0495-c-compatible-functions-and-enums/82365/4): > > This is an important feature to start gradually displacing code in C code bases with Swift, so I’m +1 almost no matter what. I do have two questions still: In Type Checking, I’m noticing that we do bridge @convention(c) “closures” to C function types, but there’s no mention of @convention(block) bridging to blocks. Can Swift implement C functions that have block arguments? In Type Checking, we specify that Int bridges. In the C → Swift direction, size\_t bridges to Int. However, in the compatib… If the Swift side uses `@c @implementation`, then the header uses size\_t and the implementer uses Int. However, if the generated header is being used, and, say, the _implementation_ of the `size_t`-consuming function calls an imported `size_t`-consuming function, the mismatch will still show up. There’s also a bit of weirdness here around _Swift_ clients of the API, which may see a `size_t` in the generated header but UInt in the swiftinterface/swiftmodule, and be unable to pass an Int to it. I guess the recommendation is “if you care strictly about matching up with C stdlib types you should use `@c @implementation`”.