# Why are opaque C pointers not imported as distinct types?

**URL:** <https://forums.swift.org/t/why-are-opaque-c-pointers-not-imported-as-distinct-types/62803>\
**Category:** Discussion\
**Created:** [January 26, 2023, 7:53pm UTC](https://forums.swift.org/t/why-are-opaque-c-pointers-not-imported-as-distinct-types/62803 "2023-01-26T19:53:47Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**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:** [January 27, 2023, 10:11pm UTC](https://forums.swift.org/t/why-are-opaque-c-pointers-not-imported-as-distinct-types/62803/6 "2023-01-27T22:11:58Z")

</div>

It’s hard to say. Swift versions apply on a per-library basis, so that you can use Swift 6 while still depending on a Swift 5 package. But what happens when the Swift 5 library vends an API that uses one of these OpaquePointer typedefs? The Swift 6 client had better see that as OpaquePointer, or it won’t find the write symbol name in the library binary. So we’d be talking about two Swift users of the same C API potentially treating the C API differently, within a single compilation.

I will note that if _you_ control the C library in question, annotating the typedef as `swift_newtype(struct)` will give you a distinct type with OpaquePointer as its raw value. Not at all a complete answer, maybe not even a good one, but it’s there.

EDIT: `swift_wrapper` is the preferred way to spell it, not `swift_newtype`! My bad. (This is the attribute under `NS_EXTENSIBLE_STRING_ENUM`.)

---

_[View the full topic](https://forums.swift.org/t/why-are-opaque-c-pointers-not-imported-as-distinct-types/62803)._