[swift-evolution] Opaque Pointers in Swift

[Félix Cloutier]

Could you do a conditional typealias?

#if OPENSSL_HAS_OPAQUE_POINTERS
typealias OpenSSLContext = OpaquePointer<SSL_CTX>
#else
typealias OpenSSLContext = UnsafeMutablePointer<SSL_CTX>
#endif

Then as long as you don't need to build one single OpenSSL that supports both, you'll be fine (although it might work anyway, I think).

A problem with OpaquePointer<T> is that it forces T into existence. Swift doesn't have a notion of an incomplete type: if you write "struct foo;" in a header and bridge it to Swift, no "foo" type is imported. And of course, if it's supported, you shouldn't be able to instantiate one, and you shouldn't be able to get a type of pointer that is not an OpaquePointer to them, because you'd be able to dereference them. (Maybe they could be imported as enums with no cases? That's how we've been doing inconstructible types so far. Not sure if it would have strange implications.)

Félix

> Le 24 oct. 2017 à 01:14, Cory Benfield via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> I wanted to discuss a recent difficulty I’ve encountered while writing a Swift program that uses a C library that has recently changed its API to use opaque pointers, with an eye towards asking whether there are suggestions for ways to tackle the problem that I haven’t considered, or whether some enhancement to Swift should be proposed to provide a solution.
> 
> A common trend in modern C code is to encapsulate application data by using pointers to “opaque” data structures: that is, data structures whose complete definition is not available in the header files for the library. This has many benefits from the perspective of library developers, mostly notably because it limits the ABI of the library, making it easier to change the internals without requiring recompilation or breaking changes. Pointers to these structures are translated into Swift code in the form of the OpaquePointer type.
> 
> Older C libraries frequently have non-opaque structures: that is, the structure definition is available in the header files for the library. When using code like this from Swift, pointers to these structures are translated to Unsafe[Mutable]Pointer<T>.
> 
> Both of these cases are well-handled by Swift today: opaque pointers correctly can do absolutely nothing, whereas typed pointers have the option of having behaviour based on knowing about the size of the data structure to which they point. All very good.
> 
> A problem arises if a C dependency chooses to transition from non-opaque to opaque structures. This is a transition that well-maintained C libraries are strongly incentivised to make, but if you want to write Swift code that will compile against both the old and new version of the library you run into substantial issues. To illustrate the issue I’ll construct a small problem based on the most widely-used library to recently make this transition, OpenSSL.
> 
> In OpenSSL 1.1.0 almost all of the previously-open data structures were made opaque, including the heavily used SSL_CTX structure. In terms of C code, the header file declaration changed from 
> 
> 
> 	struct ssl_ctx_st {
>    		const SSL_METHOD *method;
> 		// snip 250 lines of structure declaration
> 	}
> 	typedef struct ssl_ctx_st SSL_CTX;
> 
> to
> 
> 	typedef struct ssl_ctx_st SSL_CTX;
> 
> 
> At an API level, any function that worked on the SSL_CTX structure that existed before this change was unaffected. For example, the function SSL_CTX_use_certificate has the same C API in both versions:
> 
> 	int SSL_CTX_use_certificate(SSL_CTX *ctx, X509 *x);
> 
> Unfortunately, in Swift the API for this function changes dramatically, from 
> 
> 	func SSL_CTX_use_certificate(_ ctx: UnsafeMutablePointer<SSL_CTX>!,
> 	                                                  _ x: UnsafeMutablePointer<X509>!) -> Int32
> 
> to
> 
> 	func SSL_CTX_use_certificate(_ ctx: OpaquePointer!,
> 	                                                  _ x: OpaquePointer!) -> Int32
> 
> The reason this is problematic is that there is no implicit cast in either direction between UnsafeMutablePointer<T> and OpaquePointer. This means the API here has changed in an incompatible way: types that are valid before the structure was made opaque are not valid afterwards. This adds a pretty substantial burden to supporting multiple versions of the same library from Swift code.
> 
> So far I have thought of the following solutions to this problem that I can implement today:
> 
> 1. Write a C wrapper library that exposes a third, consistent type that is the same on all versions. Most likely this would be done by re-exposing all these methods with arguments that take `void *` and performing the cast in C code. This, unfortunately, loses some of the Swift compiler’s ability to enforce type safety, as all these arguments will now be UnsafeRawPointer. This is not any worse than OpaquePointer, but it’s objectively worse than the un-opaqued version.
> 
> 2. Write a C wrapper library that embeds these pointers in single, non-opaque structures with separate types. This allows us to keep the type safety at the cost of verbosity and an additional layer of indirection.
> 
> 3. Write two different Swift wrappers for each of these versions that expose the same outer types, and transform them internally. Not ideal: the conditional compilation story here isn’t good and distributing this library via Swift PM would be hard.
> 
> I’d be really interested in hearing whether there is a solution I’m missing that can be implemented today. If there is *not* such a solution, is there interest in attempting to tackle this problem in Swift more directly? There are plenty of language changes that could be made to solve this solution (e.g. changing OpaquePointer to OpaquePointer<T> but making it impossible to dereference, then treating UnsafePointer<T> as a subclass of OpaquePointer<T>, or making OpaquePointer a protocol implemented by UnsafePointer<T>, or all kinds of other things), but I wanted to hear from the community about suggested approach.
> 
> I’d love not to have to manually maintain a C wrapper just to escape Swift’s type system here.
> 
> Thanks,
> 
> Cory
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution