Improving the usability of C libraries in Swift

Re:Improving the usability of C libraries in Swift by randomNumber7 on Friday January 23, 2026 @07:59AM (#46731958)

I think Swift has great C interop but they made pointers too diffcult to use. Which of the following type do you have to use if your C API returns some pointer?

UnsafeMutablePointer, UnsafePointer, UnsafeMutableBufferPointer, UnsafeBufferPointer, UnsafeMutableRawPointer, UnsafeRawPointer, UnsafeMutableRawBufferPointer, UnsafeRawBufferPointer

?? This is comical and the only reason to make it this clunky is because "unsafe is bad" and you don't want people to use it.

[ Parent | on HN ]

Re:Improving the usability of C libraries in Swift by dagmx on Friday January 23, 2026 @09:50AM (#46733149)

Your question as stated is exactly why there are so many pointer types.

Is it a pointer to raw memory or a pointer to a type? Does it have a known size? Should it be allowed to be changed?

These are all questions you have to answer in C but cannot without annotations or documentation. Languages with more expressive type systems need to map that ambiguity to something.

[ Parent | on HN ]

Re:Improving the usability of C libraries in Swift by zffr on Friday January 23, 2026 @11:21AM (#46734318)

You listed 8 types, and this is because there are 3 axes that each have 2 values

- Mutable or not

- Typed or Raw

- Single object, or Buffer

Given one kind of pointer, you can convert to any other kind of pointer, but you are responsible for knowing if it’s safe to do.

The API is not super intuitive, but I can see how it makes it more clear what you are doing in your code.

[ Parent | on HN ]