[Swift/C++] User survey: how would you use C++ interoperability?

[dwaite (David Waite)]

@lukasa

From working on SwiftNIO and Swift Crypto I've built up a list of best-practices that might be worth thinking about. I'll put my answers below. Note that this is not authoritative and I can't claim that this is what the community wants to do, but I think I've got more experience here than most.

Thank you for this! I have used SwiftNIO minimally so far (mostly ByteBuffer for easing implementation of parsers and binary generators in projects like Cyborg, which provides CBOR tooling.)

dwaite:

Should I expose a C struct directly or hide it in a new Swift type?

You should hide it in a Swift type. In general, exposing the types of your dependencies isn't great. Wrapping the C types in Swift types gives you a type that is in your namespace and that you control, which makes it easier to (for example) add conformances to helpful Swift protocols.

This does force you to write more code than you otherwise would, but the advantage is that you can promise your types will behave in a Swifty way. This also allows you to reference count non-trivial C types to manage their lifetimes.

As an example, consider Swift Crypto's ArbitraryPrecisionInteger , a wrapper around BoringSSL's BIGNUM . This is a complex wrapper that provides lots of helper functionality ( ExpressibleByIntegerLiteral , Equatable , Comparable , AdditiveArithmetic , Numeric , SignedNumeric , CustomDebugStringConvertible ). It also takes a fundamentally referential type and turns it into a value type, making it much nicer to work with in Swift. (More on this later.)

Even there I'm missing some useful protocols: I could have given this a BinaryInteger conformance, too. I was just too lazy.

Interesting. As a slight segue here, do you see this sort of strategy changing over time - for instance, would you consider moving to a common arbitrary precision integer type such as one in Swift Numerics, or would that generally be more trouble than its worth considering the bridging between that and the needed type by an underlying crypto engine?

dwaite:

If the struct has a foo_t* as an array of entries, should I expose that as a [foo_t] equivalent in Swift, even though that means creating arrays more often?

Wrap it in a Collection type that wraps the underlying pointer. If the pointer has a length this can be a RandomAccessCollection , otherwise it's a Collection . This avoids the need to copy, while giving you most of the friendliness you want from Array s. In general when you think you want an Array what you actually want is something that can do what Array can do (be looped over, fast indexing, etc.): RandomAccessCollection is that.

An example of this is swift-nio-ssl's SSLConnection.PeerCertificateChainBuffers . This type provides access to the certificates provided by the peer in a TLS connection. This type is a RandomAccessCollection , which means it can be used essentially anywhere an Array can, but doesn't need a copy.

Since I imagine there are often similar memory management patterns within a codebase for multiple exposed types, did you ever consider building a generic type, e.g. one that works around BoringSSL CryptoBuffers and not specifically one for PeerCertificateChains?

The flip side of this I imagine is that your types may have some functional limitations because your wrapper doesn't have certain features you would get 'for free' with native swift code.

A CryptoKit/SwiftCrypto example might be that you can't initialize a digest to an arbitrary value, which limits your ability to do certain things (like implement Codable) and treat a digest as a specialized Data type.

Likewise, a PeerCertificateChainBuffers type would need to be copied into an Array for use in many API, simply because [Foo] is easier to type than RandomAccessCollection where Element: Foo (although perhaps not the best example for this class as it appears to be internal.)

dwaite:

If the struct has a foo_t* (I'll assume caller-managed memory semantics), how do I manage the memory of the imported struct on copy?

Wrap it in a class.

Any time you have an object that needs lifetime management being brought into Swift, the only way to safely manage that lifetime is to use the wrapper object in a class. In most cases you want value semantics for these things though, so you often need to then wrap that class wrapper in a struct to re-establish value semantics.

Again, Swift Crypto's ArbitraryPrecisionInteger is an example of this. It uses the CoW pattern along with a backing class that owns the C struct's lifetime. The need to involve an extra heap allocation here is a bit frustrating, but in many cases that heap allocation can be elided for objects that don't live long.

Ahh, that was somewhat my expectation but I wondered if there were any generic tools to do so, such as a malloc/free'd buffer you could leverage for the inner class and do CoW patterns on.

dwaite:

The attributes/macros/apinotes for controlling bridging are generally undocumented, except for CF_SWIFT_NAME.

I recommend not bothering to use apinotes: writing a proper Swift wrapper will likely be better in the long-run.

Have you had to deal with exposing internal types for compatibility when users want to call other C API?