A Forward Vision for C++ and Swift Interoperability

[zoecarver]

Hello, Swift community!

The C++ Interoperability Workgroup has been hard at work developing a vision for both forward and reverse interop (using C++ from Swift and visa-versa). The reverse interop vision has recently been accepted by The Language Workgroup and the forward interop vision is approaching completeness.

While The C++ Interop Workgroup and The Language Workgroup have provided great feedback, I'd like to also ask for the wider community's thoughts and feedback. Please feel free to add comments to the GitHub pull request or to this thread. Thanks in advance.

GitHub Pull Request: https://github.com/apple/swift/pull/60501
Forward Vision Document: https://github.com/zoecarver/swift/blob/docs/interop-roadmap/docs/CppInteroperability/ForwardVision.md

The role of vision documents in Swift evolution

Hello, Swift community. "Manifestos" have historically served an important role in Swift's design. A manifesto pairs a long-form analysis of the current state of one area of the project with a high-level vision for how that area should evolve in the future. It establishes common terminology, propagates key conceptual models, and sets community expectations about the direction of the project. The impact of a good manifesto can be felt in every conversation that touches on that area in the fut…

[esummers (Eric)]

The forward side of C++ interop may be useful for passing constants to Metal MSL too. Hopefully any tooling will take this in to account to make sure these headers are generated first.

[esummers (Eric)]

Looks like I got this backwards, but I still hope this reverse interop will work with Metal shader constants.

Broadly, this feels like similar goals to Google’s Carbon which I think is great.

[zoecarver]

Broadly, this feels like similar goals to Google’s Carbon which I think is great.

Yes. Interestingly enough, Google actually started this effort and wrote the first Manifesto (vision) for C++ and Swift interoperability.

While the goals here are generally similar to Carbon, there are some subtle differences, both in how much and how automatically we want to import, and the sacrifices this necessarily entails. That begin said, Carbon's interop story seems to be mostly a set of lofty goals. Their interop design document is mostly a "TODO," and from talking with Chandler it seems that they are prioritizing other parts of the language's development.

Whether these goals can be met, or are even implementable, is yet to be seen. I think there is a dichotomy when designing a successor language around interoperability; either the language will need to maintain those unfortunate constructs in the name of interoperability, or the language can be more strict and maintain strong idioms on the pain of automatic and complete interoperability. This vision proposes that Swift strike a balance closer to the latter. It seems that Carbon leans closer to the former.

In any case, languages take a long time to develop. If programmers want to move away from C++ in this decade, or if they want a language with modern features, such as memory safety, library evolution, error handling, etc., Swift will be a better option then Carbon.