CppCast - Swift and C++ Interoperability

Episode Date: March 17, 2022

Dave Abrahams joins Rob and Jason. They first talk about JeanHeyd Meneid's blog post on saving C's ABI. Then they talk to Dave about his history as a founding contributor of boost and the current workgroup he is a part of to enable bidirectional interop between swift and C++. News To Save C, We Must Save the ABI Jluna C++ interop for Julia Emulating template named arguments in C++ 20 Links Swift and C++ interoperability workgroup announcement C++ Interoperability Status Getting started with C++ Interoperability Interoperability between Swift and C++ Patreon CppCast Patreon

Episode 341 of CppCast with guest Dave Abrahams, recorded March 16th, 2022. This episode of CppCast, we're thanking all of our patrons on Patreon. Thank you so much for your ongoing support of the show, and if you'd like to support the show too, please check us out at patreon.com slash cppcast. In this episode, we talk about saving C's ABI. Then we talk to Dave Abrahams from Adobe. Dave talks to us about his history with Boost and C++ Swift interoperability. Welcome to episode 341 of CppCast, the first podcast for C++ developers by C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? I'm all right, Rob. I managed to do training last week. Yeah, how did that go? It was great. Nice being in person with people again? I was in person with people again, yes. And, you know, just statistically around here, it seems like it was a safe thing to do and everything seems to have worked out.

Hopefully, we'll be returning to a state where that's possible in more places. Yeah, hopefully. They did just lift the mask mandates for schools here. We're telling our kids, you know, just keep the mask on at least for another two weeks because we were kind of just expecting there to be, you know, an influx of new cases. Yeah, like a giant mask off. Yeah, hasn't happened yet. So hopefully, you know, we'll be able to take masks off next week. Denver Public Schools dropped their mask mandate two weeks ago, and from what

last I looked, we did not see any resulting spike from it. So it looks like the moment things are... I do think it's going to be one of those things where we'll probably get a booster again in the fall and maybe even a mask again in the fall and winter. But hopefully, you know, we can enjoy this spring and summer like it's a normal world again. It would be wonderful. Well, on that note, about it not being so much of a normal world right now, a lot's been happening over the last few weeks, especially this past week, which both directly and indirectly affect the C++ community, of which we are a part of. Jason, you and I were talking about all this before the show

and just wanted to put out there that we stand with the people of Ukraine and at the same time support our friends in Russia who do not support the invasion of Ukraine. Obviously, we've had lots of Russian guests on the show before, and I'm sure we have lots and lots of Russian listeners. And I know that not everyone in Russia supports this invasion. It definitely seems like it's coming from the top down. In the same way that we never hold any individuals responsible for the actions of our governments, we don't hold Russians responsible for what's going on, individual Russians. So additionally, there was also some recent discussion in the C++ community. We're not going to talk about any details about this right now, but if you're on the C++ subreddit,

if you follow people in C++ on Twitter, or if you're on the Include Discord, probably aware of what I'm making a reference to. Maybe we'll talk about it more in the future, but we're not going to talk about it now. But we do want to wish healing for all members of the community. I hope that we can find a way to move forward that provides a safe environment for everyone. Well, at the top of every episode, I'd like to read a piece of feedback. We did get this tweet from last week's episode saying, I've definitely needed std is debugger present in the past. My example for embedded systems is in a hard fault or bus fault. When the debugger is attached, I want to halt and let the developer examine the state.

Otherwise, in normal operation, attempt a recovery and reset. I can see that. So if you put a signal handler, what do you call it? Install a handler for a fault in your embedded environment and then be able to trigger the debugger. I could see that. Yeah, that's definitely what I've used it for in the past, like in some error handling code,

have this as debugger present so that you can let the developer see everything that's going on and not just work, have it log everything. All right. Well, we'd love to have your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave this review on iTunes or subscribe on YouTube. Joining us today is Dave Abrahams. Dave is a contributor to the C++ standard, a founding contributor to Boost and the founder of BoostCon, and was a principal designer of the Swift programming language. He recently spent seven years at Apple, culminating in the creation

of the declarative Swift UI framework, worked at Google on Swift for TensorFlow, and is now a principal scientist at Adobe, where he and Sean Parent are booting the software technology lab. Dave, welcome back to the show. Hey, it's great to be back. How does it feel, Dave, to basically, I mean, you created the first C++ conference, really. As far as I know, it's the first C++ conference. Yep, I think it's the first. Yep. Although with your career, whatever, you didn't attend so often in the last several years.

But you were at CBPCon this year, I think. Yeah, things have changed a bit. But especially when I got to Apple, they really didn't like their engineers to talk to anybody outside of WWDC. Because sometime in the previous decade, somebody had gone to a conference and said something they didn't like. And, you know, Apple's a very top-down organization. It seems like there's better ways of handling that. Like, just get your talk approved beforehand, not just, you can't ever speak, but okay. Or just say, we hire you. Well, no, no, no, no. You could get approval to go talk.

You would just have to go through a senior vice president. Oh, wow. Well, everyone has direct access to a senior vice president at Apple, right? Well, to give them foot rubs and things like that. That's terrible. No. Well, welcome back. Anyhow.

I'm much happier with Adobe. Are you planning to go to C++ now, this year? I am. I am very excited to go to C++ now. Will you be speaking? I hope so. They have not announced the speakers yet, but yeah, I think there's a good chance that I'll be speaking and possibly keynoting. Possibly. Possibly.

Possibly. I have to say possibly because they haven't... They haven't announced anything yet, I see. Well, that should be fun. Do you still silently call it BoostCon in your head, though? You know, I trained myself out of it for a while, but once CppCon came along, I think it totally weakened the brand of C++ now because, you know, it's CppNow, CppCon, everybody, you know, same number of letters. Three of them are the same exactly.

And at this point, I would support a return to calling it BoostCon, especially because I think, you know, people come from other language communities, too, to talk in BoostCon and bring all kinds of influences in. And I think being so singly focused on C++ in its name maybe doesn't serve it. That's an interesting point. Can you remind us what year that actually was, the first? I wish I knew. I could probably find out just by going to the web and looking at the C++ Now website. They have their own timeline because it was the 10th anniversary like three years ago, I think. I think that might be right-ish or something like that. Cause you came for that anniversary,

right? For the 10th anniversary one, I think 2008 then. It's a little hard to remember. Um, yeah, sorry. Yeah.

Well, thank you anyhow for starting the C plus plus conference revolution. Thanks so much. I was really, really proud of how BoostCon turned out. And, you know, also not because of just my own work, but how the community came together and stepped up and generated this thing as, you know, as volunteers every year. I'm really excited to go back.

It's a wonderful place, and it still, as far as I understand, reflects my original vision for that conference. Cool. Well, Dave, we've got a couple news articles to discuss. Feel free to comment on any of these, and I'll start talking about Swift and Swift Interop. Okay. All right.

Okay. So this first one is a post on John Hedemaneed's blog, and it is to save C, we must save ABI. To save C. To save C. Yes. Yeah. So it's an extremely long post, but worth reading.

Yeah, John Heed's opinion on C++ and ABI, I believe, is still the same, that he thinks we need to break it or acknowledge its existence, maybe. The ABI in C is important, but he does have a solution for some of the ABI problems you can run into with C. So in this post he goes into aliasing functions, which seems like it should be a good solution for some of those problems, right? You mean pointer aliasing stuff? It's function renaming, basically. So let the linker sort out the details. And in this version, the function, it's basically applying mangling, like opt-in name mangling, basically. So they have the option to change intmax-t. Intmax-t is the thing that keeps coming up in the article, that it has to be 64-bit from now and forever more. But the C committee is like, well, can we have 128 bit at max t and if they're

going to do that then he's providing an option here to say well we can do some manual aliasing of the function so if you try to call the version of abs that expects 64 bit at max t then it'll dispatch to this version of the function otherwise it'll and it's all comes down to like basically linker foo but manual opt-in name mangling effectively yeah it sounds like this is about api evolution with stable abi so that you don't break existing code that was actually a big concern for the design of swift. And I think it's still only a sort of a partially explored space, but it's important stuff. It reminds me of a technique I recall seeing at least 10 years ago, but I don't see come up very often now. namespace whatever, JSON, and then down in there, namespace version two, namespace version three, namespace version four, whatever. And then you do a namespace alias. So you're like, well, just reassign JSON to version four. Then you get clean, easy to use call syntax. No one cares what

version they're calling when they compile. But then when you link, they would have a different linker symbol because it would be, are you calling version 4 or are you calling version 3? And then things would blow up at least at link time to stop you from getting into ABI trouble. And I've never used the technique, and I haven't seen anyone talk about it recently,

so now I'm kind of curious about peeing that off of John Heed. Isn't that what inline namespaces are all about? Yeah, that as well. I mean, I have to admit, I don't really know many of the newer C++ features. You know, by my standards, that's a newer one. Right.

Because I'm old. So I haven't used it, but that was my impression, is that that's what they were trying to do with that. Yeah. I don't really understand why we don't use it so much. I guess I need to understand it more. Yeah. Well, if you have a lot of features you don't understand, there's a lot you're not going to use, right?

And no one said that there are too few features in C++. What about all those people that are writing proposals for you? I still think that they agree that there's already a lot of features in the language. There's still new features I want, that's for sure. There's not too few features, but there are missing features that we need.

Yeah. Yeah. So, I mean, you know, one of my big frustrations with being on the committee was that there didn't seem to be any path toward, you know, getting rid of stuff. I mean, you know, a couple of things got deprecated, but, you know, I think this goes to what you were talking about in your news article. There's no agreement in the community about whether it's okay to break binaries ever or break source code ever. And the concern about breaking source code is really kind of hilarious because every time we put any new name in the standard, we're going to break some hypothetical source code. It shouldn't be a question of whether something could theoretically break. It should be a question of whether, you know, this is like commonly used.

You know, there's going to be a lot of breakage. The committee never was able to sort of sort out criteria for making those kinds of decisions. One of the things that John Heade addresses in this article, and he's coming from the C committee perspective, is in a lot of these cases where, you know, theoretically we say we want to do X, but the implementers ultimately end up having the final say because they say, sorry, that would break our existing code or sorry, we can't implement that or whatever. And so John Heade's argument here is that it's really the implementers who decide what ends up in the standard, not the standard telling the implementers what to do. Yeah, I mean, that's true. And in this C++ world, you've got, you know, some of the implementers now kind of have a somewhat vested interest in not making any changes. At least the, you know, Clang is fairly far behind, right? And so anyone whose job it is to get to move Clang forward

is going to be daunted by extra features. Next thing we have here is JLuna is a Julia C++ wrapper. I think we briefly mentioned Julia a while ago, Jason. I can't remember which episode it was on, but I think we have talked about it. It has come up at some point. So apparently Julia has a C API, which is available, but apparently not very well documented. So the goal of this project is to have a nice, easy-to-use C++ wrapper around Julia. Did you have a chance to easy to use C++ wrapper around Julia.

Do you have a chance to dig into this one much, Jason? I did not. I mainly put it in here because of Dave's experience with Boost Python, because wrapping other programming languages is its own thing entirely. Well, yes. I'm just looking at the Reddit thread, which just has a little example in it. I can't really tell what the mechanism is here. It looks like they're embedding some Julia script right into some C++ code.

That does seem to be the main goal is to make it easier to call Julia from C++. Yeah, a language interrupt problem always sort of has two sides. And if they've only thought about calling Julia from C++, they're missing something. But, you know, normally, if, you know, you have a language with function pointers

that you're interfacing with, you know, function pointers or closures or whatever, then as soon as you start, you know, trying to figure out how to call into that language, you have to also work out how to let that language call you back because you have to pass it some kind of function or something. Right. And then it becomes a two-sided problem.

So I don't know how far they've gotten into that. That's a very good point. Maybe we should find someone to talk about Julia in more detail at some point, though, Jason. That would be cool. It's a pretty cool language from what I hear. I have not used Julia or really looked at it at all, in fact. And the last post we have here is a blog post titled Emulating Template-Named Arguments in C++20. And this is a pretty interesting stud map

that has the two required template arguments and then three that are not required. You have default values for, and you want to put in a custom allocator. You have to put in your hash and be equal as well, even if you just want to use the defaults. And this author found an interesting way around that by using designated initializers. Designated initializers with class template argument deduction in a template struct that deduces the other arguments for you and then forwards them all to the map

i'm very impressed by this not because i think it's like a good technique that everyone should use but because of the amount of c++ that you have to understand to understand how the technique is working i feel like it's just like for our readers or excuse me for our listeners would be like just a great thing to read through and understand what it's doing. I thought this was totally creative. It's not a solution I would have ever come up with. Yeah, it reminds me a lot of what I did with the Boost Parameter Library,

which was about getting generic named parameter passing syntax into C++. And, you know, there's a giant pile of metaprogramming that gets used to do this. And I find we're doing this sort of thing all the time in C++. It's like sort of trying to invent the language feature in a library that the language won't give us. And I guess, you know, once I had people who would build a core compiler for me, you know, working on the Swift project, I became a lot less interested in sort of emulating language features. That's funny.

It's fun, though, in a way. I mean, you know, it's a puzzle. Yeah, it does. You know, it has a lot of overheads, right? Like, I mean, should people use this? People get nervous about using a library like that because it's so complicated. And then if they're especially in a system that doesn't have separate checking of generics, you know, as soon as something goes wrong, it goes wrong inside your library. And now the users who were just trying to get a nice name parameter feature

are exposed to all the guts of that thing. Dealing with 10,000 lines of errors from the compiler and trying to figure out which one is relevant to them. Yeah, yeah. So Dave, I think today we mostly wanted to talk about Swift and Swift C++ Interop. But before we go into that, do you want to tell us a little bit about your history with the Boost project since you did mention that in your bio? Boost. Well, I wasn't at the moment when Boost was first mentioned. So that apparently happened at, I don't remember which committee meeting, somewhere in Europe. And Beeman Dawes was the Standard Library Working Group chair, the late, great Beeman Dawes, who passed just in this past year, I think.

And this was shortly after the first standard, so 1998. He was thinking about where are the libraries going to come from for the next standard. And the committee has a charter to standardize existing practice, which means things that have been out in the world under use and have been somewhat proven useful and workable. But if you look at the C++98 standard, we didn't necessarily sort of hew to that ethos. It was fantastic that the committee recognized the brilliance of the STL and standardized it, but it really hadn't been used at all when they did that. And in fact, there were several major C++ features that weren't in the language yet

that the library design called for. So they standardized the STL and then they developed the language features to support it. But as I've said before, it's a singular work of genius, right? So you don't do that for every library that comes along. So B. M. E. was wondering where are we going to get these libraries from for the next standard? And he started to have this idea of this organization where we would develop potential libraries for the standard as open source. Yeah, so there was a discussion he had with Robert Clare because Java

was really hot at the time and they were thinking about drink names. And so somebody came up with the idea of booze instead of Java because, you know, you've got to have the opposite mind-altering effect. So anyway, I think that's where the name Boost came from. But, you know, after they came back from that meeting, Beeman started organizing discussions. And I was in one of the very early groups setting this up. And we decided, you know, what we wanted to do was get these libraries out into wide use. And so we would make them open source and commercial friendly and try to make them also really high quality and use kind of the same kind of process for reviewing them that would get used in the committee so that they really get scrutiny both on their way in and, you know, continual feedback from the community during their life. And this was a really exciting project for me. We started out, I don't even know where we kept our source code.

I mean, I don't think we even had a CVS repository in the beginning. So eventually it became CVS and then Subversion. And then finally, after a heck of a lot of work to separate everything out, we got it into Git just before I went into my permanent installation inside of Apple. Semi-permanent. Ten years. So yeah, that was Boost. I guess, you know, it was certainly a big success for C++03. I think we got 14 libraries into C++03, including std function, shared pointer,

a whole bunch of type traits. There's lots I can't remember. But yeah, so that was really significant. And it's continued to grow since awesome yeah we mentioned your work on boost python moment ago i'm talking about the julia thing do you have any plans on going back to boost python no absolutely not i mean no it's it's been redone in a more modern style by somebody who built this thing called Pybind 11. It was C++11. My collaborator on Boost Python, Ralf Gross-Kunstlieb, who maintained Boost Python for a while after I moved on to other things, actually, as part of his job at Google has been developing PyBind 11 and bringing in the parts of Boost Python that PyBind 11 didn't do so well with handling inheritance hierarchies and things.

So I believe for that particular approach and those two languages, PyBind 11 is probably the future. I shouldn't try and compete with it, right? So it's got momentum. Sure. I had always thought of PyBind 11 as like a competitor to Boost Python. I never really thought of it as like the next evolution of Boost Python and the lessons that were learned there moving forward or whatever. Well, you know, they did miss some points, but the way PyBind11's page describes it, it's Boost Python only more modern and, quote, the biggest problem with Boost Python is Boost. So it's a thing with no dependencies other than the standard library. You know, I can understand why they would do that. If Boost Python was getting a lot of attention, I would consider it competitive, but I don't think very much has been going on with it

since I left Boost. Yeah, I looked at it for a curiosity. I think it was 2016 was the last time an update was published to Boost Python. So that's one reason I was curious about. It's a while back. Yeah. Hey, everyone.

Quick interruption to let you know that CppCast is on Patreon. We want to thank all of our patrons for their ongoing support of the show. And thanks to our patrons, we recently started using a professional editor for CppCast episodes. If you'd like to support the show too, please check us out at patreon.com

slash CppCast. So, Dave, we had this news article in our news a couple weeks ago, Swift and C++ interoperability workgroup announcement, and you are mentioned as one of the initial set of participants on this list. Can you tell us a little bit more about this workgroup and what its goals are? I can say it's generated coming out of Apple and understanding as much as anyone from the outside can understand Apple's goals is that

Apple is going all in on Swift. And they, like most everybody else, has a substantial amount of C++ code, including the Swift compiler, which is written in C++. And you want to be able to build new tooling for Swift using the Swift compiler in the same way that you would build tools using the Clang libraries for something like Clang-Tidy. All of those kinds of things require a strong interop story. But Swift is not probably, I would guess, not Apple's, you know, the Swift compiler is probably not Apple's main client for this. There would have to be a really substantial amount of other code that could benefit from Swift interop for them to invest as much as they have in this. So that's from Mapple's point of view. I guess if you look at what Swift does with Objective-C, if you have Objective-C code, you can just use it from Swift. And it's like basically full fidelity.

There's a few stylistic changes. It certainly doesn't use Objective-C syntax, but it uses Swift syntax and Objective-C classes act just like Swift classes in Swift. And you can pass your Swift classes to Objective-C, at least if you mark them right. I don't remember the details, but anyway, it's very seamless. That's the main point. You don't have to go and write some kind of a wrapper layer. There's no JNI to do. You can create layers to present a different interface than you would get by default in Swift. So I think the goal of the C++ Interop group is to do something very similar for C++. The challenge, of course, is that Swift was only designed with this possibility

sort of remotely in our minds rather than as a 1.0 goal. In order for Swift to be a success, it had to interop with Objective-C because that's what all Apple developers were using. And all of the Apple SDK's frameworks were written in that language. And so there are a number of real differences between the languages that make this a really interesting problem. One question I had, and i think you may have just answered it for me is i was kind of curious if there was any existing support for swift to c++ interop and i know that in objective c i think you can have objective c++ and do c++ that way from objective c so i guess if you need to get to C++ today from Swift, you could do Swift to Objective-C, including C++.

To Objective-C++ to C++. Yes, you absolutely can do that. The thing is, you know, Objective-C is a superset of C. techniques that we used for C interop, which is fine, but not great because you'll lose memory management and lifetimes and all the information you get about things from C++. Or what you're doing is you're embedding your C++ types inside of Swift classes or Objective-C classes so that they can move across that boundary seamlessly. Each one of those things is a dynamic allocation with reference count. And so if you're doing systems-level programming in C++,

this is not a great way to interrupt small components. If you have a large machine learning system or something like that, and you want to pass it across the boundary that way, that's not such a big deal. But if you're trying to do something like with STD complex, you don't want to be allocating an object for each of those. Is the goal, as far as you know it, to get the C++ interoperability on par with the objective C interoperability? That's an interesting question. I mean, one of the things I've been trying to get the group to do is to sort of write down what it is we think we're shooting for. And I hope we're going to have that discussion soon. But one of the things we brought up is,

do you need to be able to use all C++ components from Swift? And do you need to be able to use all Swift components from C++? And if you do, it's interesting because there's a number of things that should kind of be collapsed into higher level notions when you import them into Swift. But occasionally, you need to distinguish them from each other if you want access to the full C++ API. And gosh, I wish I could even remember. I'm going to come up with a really bad example, but likely you don't want to see volatile anywhere in your Swift code. We don't have a representation for volatile and that should normally be collapsed away. But if you have a template specialization on

volatile int or whatever, you may need to be able to access that and use it. And so the problem of just, you know, naming those C++ entities and accessing them becomes interesting because there's no direct representation in Swift of the same ideas. I feel like a lot of these questions about interoperability in a way are easier with a scripting language, JavaScript, Python, whatever, because you don't have to worry about calling conventions so much, but you're talking two different compiled languages, right? We've got Swift as a compiled language and C++ as a compiled language. It sounds like ABI is now something you have to worry about, right?

And if you're going to call a C++ function directly, is the goal to set up the call stack directly and then immediately call that function? That sounds tricky. Yeah, I mean, that's the way we interrupt with C. I don't think the ABI challenges are hard there, at least for one platform. I guess the problem is if porting this system to multiple different platforms,

if they have different ABIs, then you have to code those individually. But the same basic issue had to be solved for C interrupt Rop on each platform. So I don't consider that a huge challenge. I think the bigger problems are actually that, you know, Swift wasn't designed with any non-copyable types. So there is no way to realize that we need to solve sort of the fundamental base layer language problems. Sorry, I should say Swift always wanted to support non-copyable types down the road somewhere. But there's not a complete design and there's certainly not an implementation of it. So, you know, in order to figure out how to interoperate with C++, you definitely need to make some decisions about

that stuff. And then there's another interesting problem, which is that because of how things shook out with, well, I'll tell the story in more detail if you ask, but in Swift, copying anything is an order one operation. So when you copy an array, because all variable size things, you end up using copy on write if they're value semantics. Okay. So the copy is order one. Okay. And so you can program with that sort of, with that mentality.

But in C++, you know, we can't be just copying vectors willy-nilly, right? So there's a question of, like, should you even copy any C++ types implicitly? Or do you have to represent copying a vector as a different thing? We can't wrap a std vector into a reference counted thing while we're handling it. There's no way to do that without actually moving it. You don't want to do that. So I think there

are some very basic issues at the object model level that need to be worked out. And those are the things I'm most interested in this project, aside from generics, which I think also have some really unique challenges because Swift generics are separately compiled. They get compiled into basically something with a dynamic dispatch mechanism. They still have static polymorphism semantics, but they use function pointers essentially do the dispatch and then that gets optimized and specialized at a later stage. So that's a very different model from templates where you wait until instantiation time and resolve overloads and the meaning of the inside of the thing can completely change on you depending on the specific type parameters you're putting in. And so how we bridge that gap is an interesting

question. That does sound like an interesting question. Also kind of reminds me of how Java generics work, I guess, in a way, right? It doesn't have the expressive limitations of Java generics. It's more like Haskell type classes. So it has associated types. It uses type erasure, but it doesn't mean that everything ends up getting boxed, for example. So that's all part of the API resilience model of Swift, is that if you have an array of some struct and you add a member to that struct, it doesn't have to break clients, but it's still laid out in line. So the size of the struct ends up being a dynamic parameter across that resilience boundary. Interesting.

If that makes any sense. It makes any sense. It makes some sense. I think we may have touched on this a little bit when talking about Julia earlier, but usually when we talk about C or C++ interop, I think it's kind of usually going one way. But this workgroup is pursuing bidirectional interop. What are the goals of that? What will bidirectional interop enable? By the way, I went and I looked at that Julia page, and they do go bidirectional. Okay. Yeah, if you look at their GitHub thing.

Well, like I said, as soon as you want to do unidirectional interrupt with full fidelity, you have to interrupt in both directions. And even if you forget about closures, function pointers, and lambdas. You have to be able to convert types in both directions because you have function parameters and function returns. So you're calling into another function. You have to go both ways. So I think it's basically just part of what you need to do in order to provide a complete picture. So that's the mechanism for going both ways.

As for specific support in the, let's say we're modifying Swift to interrupt with C++, question might be, what specific support do you need on the C++ side to be able to more conveniently call into Swift? And can you do that without substantially extending C++, which I think is something to be avoided, right? So my hope is that we can find a way to do that with libraries. But does that answer your question about why do you want bidirectional? I think so. I mean, we just discussed the fact that we can emulate lots of things that we wished were language features as library things in C++ if you're creative enough.

So you probably have a solution there. Yeah. For most purposes, I think the goal of C++ Interop is not to make programming in C++ easier. I think the people working on it don't feel like that's too big a challenge to take on, right? So what is the current status of this working group? Like any specific decisions or is there any current test code that someone can play with if they want to interop with C++? There is something you can play with if they want to interrupt with C++? There is something you can play with.

I actually asked this question on the Slack channel and got an answer sometime back, and I can dig it up, but I don't have it at my fingertips. So, yeah, I mean, maybe the thing to do would be when I find it, we can post it at the end of the session. So they're able to import a whole bunch of things from C++ into Swift and to use concrete instances of generic types, you know, std vector of int, but can't use vector of t from inside of the generic, I think. Something like that is the limitation. Yeah, as far as I know, move-only types just haven't been figured out. I don't know whether they've settled on whether to make all C++ types that are copyable, implicitly copyable in Swift. I think if copying a thing in Swift becomes order N with the implicit copy instruction, I think that could be kind of bad for the programming model. So anyway, we're still trying to figure that out. I kind of want to jump back on this real quick,

because you had said before that your personal main interest was in the generic template kind of space, if I understood that right. So do you actually hope, and thinking about the vector event problem, do you actually hope that at some point in the future, you could directly use standard vector in Swift and pass in a Swift type? Yeah, you can. Okay. You can do that now. So there's some level of interoperation that's difficult because Swift generics have to be separately checked. And if you have a template foo of T and you use it inside your generic, you have to draw some conclusions about whether that usage is correct or not. And they're checked against concepts, you know, protocols is what we call that in Swift. But there aren't any constraints on your C++ template to go by.

And you don't know until you get a concrete T whether the usage is going to be correct. What this implies, this implies a number of things, which is like any Swift generic that uses a C++ generic needs to be what's called monomorphized, which means that you have to finally unwind all of that dynamic dispatch and get down to a concrete T. And then when you do that, you have to do some checking again. You know, the way I see it, what we'd like to do is avoid creating a situation where you see errors in Swift code, in Swift generics, after an instantiation backtrace in Swift, effectively.

You can't avoid the idea of an instantiation backtrace in C++, but let's have it stop at the boundary with Swift so that it maintains that kind of pure quality of the Swift language. So do you then have to dispatch out to a C++ compiler at some point to actually instantiate the C++ template that's being used from inside of Swift? Yeah, well, there's a copy of Clang inside of the Swift compiler already. Yeah, that's how we do the interrupt with Objective-C. Okay. Oh, okay. Right.

That clears some things up. Yeah. Yeah, it's not that we're lacking the facilities. I see. We just need to figure out the semantics. That could be a solution for the Rust C++ interoperability question right there, too. Just embed Clang into a Rust compiler, yeah. Yeah, but if I understand right, the Rust people are even uncomfortable with the fact that their compiler is written in C++.

And so embedding Clang would make them even more uncomfortable, I think. I have a friend who we're in discussions about him helping me with some marketing kinds of things for my channel and whatever. He's like, what is C++ actually used for? I'm like, everything? It's everything. You can name an industry, it's everything. And he's like, oh, okay. Well, Dave, it was great having you on the show. This work group was first announced just in January, and I'm wondering, do you have any concept

how long it might be until there's, you know, something that can be used? Obviously, you're going to put that link in the show notes. How far away do we think the Swift Interop might be? It depends on what you think complete support means. That's number one. Number two, you know, I have to say I'm participating mostly as an advisor and an interested observer at the moment. It's possible that we could get to the point where it makes sense for Adobe to invest actual resources in this. The work group was announced. It's only March, so we've been just getting a few meetings going. I missed a meeting because I was on vacation.

So like this is really early stages. I want to be clear. So if I had to guess, I mean, you know, it's a WAG, a wild guess. If I had to guess, I would say two years, you have something that's production ready. I'm sure it sounds interesting to lots of our listeners and they might check out the links that we do have available

and maybe get involved. Cool. Thanks for coming on the show, Dave. Thanks for having me. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in,

or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Left2Kiss on Twitter. We'd also like to thank all our patrons who help support the show through Patreon.

If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.