# Desired Swift language features that can advance the state of C++ interoperability support **URL:** \ **Category:** C++ interoperability\ **Tags:** cxx-interop\ **Created:** [July 13, 2023, 9:48pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144 "2023-07-13T21:48:50Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Alex\_L](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alex_l/32/6202_2.png) [@Alex\_L](https://forums.swift.org/u/Alex_L)\ **Post date:** [July 13, 2023, 9:48pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/1 "2023-07-13T21:48:50Z")
Swift 5.9 can import and use a wide array of C++ types in Swift. However, not all types categories are supported. This post lists the set of desired Swift language features that would allow us to support most C++ types in Swift: - Generics support for non-copyable types. While Swift 5.9 added support for [non-copyable structs and enums](https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md), these types still are not allowed to be used as a generic type argument. This is a key issue that prevents us from fully completing support for move-only C++ types in Swift, as we need to form types like `UnsafePointer` without language restrictions. - Adding to the point above, types like `UnsafePointer` and `UnsafeMutablePointer` should provide support for borrowing and mutably borrowing the non-copyable pointee. - Non-movable/non-escapable Swift type category. A non-escapable and non-copyable Swift type would allow us to import and model non-copyable and non-movable C++ types in Swift. Additionally, the following language features would help improve ergonomics for some of the common operations performed on C++ types in Swift: - Ability to perform a borrowing for loop over a Swift Sequence, that does need to go through a `IteratorProtocol` but rather can use indexed iteration instead. This would let us use `for` loop on non-random access collections like `std::map` automatically. I would like to bring the items listed above to the attention of the [@language-steering-group](https://forums.swift.org/groups/language-steering-group) to make sure that their plans and ideas for evolution of Swift can factor in these requests into account as well. ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [July 13, 2023, 10:09pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/2 "2023-07-13T22:09:12Z")
Thanks Alex. These sound in line with projects we plan to round out noncopyable types support in general, which is nice. Would it also make sense to include `internal import` on this list, as well as support for importing C and C++ types without transitively exposing their ABI, in order to allow packages to use C++ interop internally without requiring dependents to know about it? ---
**Author:** ![Alex\_L](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alex_l/32/6202_2.png) [@Alex\_L](https://forums.swift.org/u/Alex_L)\ **Post date:** [July 13, 2023, 10:14pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/3 "2023-07-13T22:14:02Z")
Yeah, great point, I forgot to include these items as well. ---
**Author:** ![David\_Catmull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_catmull/32/1007_2.png) [@David\_Catmull](https://forums.swift.org/u/David_Catmull)\ **Post date:** [July 13, 2023, 10:38pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/4 "2023-07-13T22:38:58Z")
I have on occasion used C++'s ability to use integer values rather than types as template parameters, as in `template`. Just recently I found myself wishing I could do that in Swift. I imagine that would be a significant undertaking to add to Swift generics. ---
**Author:** ![plotfi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/plotfi/32/14061_2.png) [@plotfi](https://forums.swift.org/u/plotfi)\ **Post date:** [July 13, 2023, 11:17pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/5 "2023-07-13T23:17:37Z")
Rust calls these const generics I believe, and they took a long time to get them into even the unstable version of the language. I’m not aware of the effort it would require to bring these to Swift. ---
**Author:** ![plotfi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/plotfi/32/14061_2.png) [@plotfi](https://forums.swift.org/u/plotfi)\ **Post date:** [July 13, 2023, 11:21pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/6 "2023-07-13T23:21:49Z")
Can we have a discussion on how we’d like to pursue inheritance and polymorphism? I am very eager to learn more about this and help move it forward. ---
**Author:** ![Alex\_L](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alex_l/32/6202_2.png) [@Alex\_L](https://forums.swift.org/u/Alex_L)\ **Post date:** [July 14, 2023, 12:07am UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/7 "2023-07-14T00:07:34Z")
We have had some adopter requests for supporting non-type template parameters. So perhaps the language workgroup could consider whether Swift could support some non-type generic parameters as well. Additionally, we had some requests related to supporting complicated templates where the user wants to choose whether to specify a default template parameter or not. So perhaps Swift could consider supporting default values in generic parameters as well. I think default values would be more interesting as in principle you could model a useful subset of non-type template parameters as types and bring that into Swift in a different manner, so there's some limited workaround for non-type template parameters, but not really for default values. I suppose perhaps variadic generics could help here, as you could instantiate different template based on the the number of generic parameters 🤔 ---
**Author:** ![Alex\_L](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alex_l/32/6202_2.png) [@Alex\_L](https://forums.swift.org/u/Alex_L)\ **Post date:** [July 14, 2023, 12:38am UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/8 "2023-07-14T00:38:33Z")
For sure, I can start a new thread about that. ---
**Author:** ![Alex\_L](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alex_l/32/6202_2.png) [@Alex\_L](https://forums.swift.org/u/Alex_L)\ **Post date:** [July 20, 2023, 11:52pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/9 "2023-07-20T23:52:34Z")
Another thing that would be good to have are borrow/inout bindings. Additionally, if we can have `if borrow x = ` that's equivalent to `if let` that would be cool. We could then have a more workable and null-safe ability to work with `shared_ptr` , for instance we could then mutate the pointee using something like this: ```swift let ptr = std.make_shared(std.string.Type) if inout x = ptr.pointee { x.append("mutation") } ``` where `pointee` would have `_read` and `_modify` accessors that yield `nil` or `element_type`. ---
**Author:** ![fan](https://avatars.discourse-cdn.com/v4/letter/f/df788c/32.png) [@fan](https://forums.swift.org/u/fan)\ **Post date:** [September 26, 2023, 3:12pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/10 "2023-09-26T15:12:28Z")
We hoped for that for years when we worked on the SwiftFusion project (before S4TF went away). Turned out to be harder than we thought, and we decided to use `gyb` to generate source files. Not ideal but kinda works. CC @David_Catmull ---
**Author:** ![mrousavy](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mrousavy/32/42302_2.png) [@mrousavy](https://forums.swift.org/u/mrousavy)\ **Post date:** [December 19, 2024, 11:39pm UTC](https://forums.swift.org/t/desired-swift-language-features-that-can-advance-the-state-of-c-interoperability-support/66144/11 "2024-12-19T23:39:56Z")
I've been working with Swift \<\> C++ interop very extensively the past few months, and while it's totally awesome so far, I am often hitting two major issues: 1. Swift errors cannot (yet?) be caught in C++, and vice-versa 2. Swift protocols are not (yet?) available in C++