# \[Accepted\] A vision for using C++ from Swift

**URL:** <https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274>\
**Category:** Announcements\
**Tags:** cxx-interop, visions\
**Created:** [May 31, 2023, 2:11am UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274 "2023-05-31T02:11:32Z")\
**Posts on this page:** 11\
**Page:** 2

<div class="post-metadata">

**Author:** ![tgoyne](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@tgoyne](https://forums.swift.org/u/tgoyne)\
**Post date:** [June 7, 2023, 6:25pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/21 "2023-06-07T18:25:30Z")

</div>

I think that you are trying very hard to find offense in some fairly banal statements. Adding a lot of flowery language in an attempt to come off as uncritical of C++ would help nothing and merely make the document more confusing.

---

<div class="post-metadata">

**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\
**Post date:** [June 7, 2023, 6:28pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/22 "2023-06-07T18:28:43Z")

</div>

> [@Karl](#):
>
> For example, APIs such as `String.withUTF8` never include the word "unsafe", and most call-sites will never see that word. Yet it gives you an unsafe pointer, and you can walk over the end of it, deallocate it, whatever you like. How is that any better than C++?

It's not. This is a defect in Swift, one which we are working very hard to solve\*. We can't do that if we pretend that it's not a defect.

(\*) we can probably never eliminate these API entirely, because sometimes you actually need a pointer to hand to languages that only use pointers, but we can make it so most normal programmers never have to reach for them when working in Swift (and maybe never have to reach for them when interoperating with annotated C and C++ API either).

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [June 7, 2023, 6:29pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/23 "2023-06-07T18:29:58Z")

</div>

To be specific, I think we should include this summary [from swift.org](https://www.swift.org/about/) at the beginning proposal:

> Safety
> 
> Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code. Variables are always initialized before use, arrays and integers are checked for overflow, and memory is managed automatically. Syntax is tuned to make it easy to define your intent — for example, simple three-character keywords define a variable (`var`) or constant (`let`).
> 
> Another safety feature is that by default Swift objects can never be `nil`, and trying to make or use a `nil` object results in a compile-time error. This makes writing code much cleaner and safer, and prevents a common cause of runtime crashes. However, there are cases where `nil` is appropriate, and for these situations Swift has an innovative feature known as **optionals**. An optional may contain `nil`, but Swift syntax forces you to safely deal with it using `?` to indicate to the compiler you understand the behavior and will handle it safely.

I think that gives an appropriate background, and it's grounded in specifics so it comes across as much more reasonable.

* * *

> [@tgoyne](#):
>
> I think that you are trying very hard to find offense in some fairly banal statements.

Well, I thought it was quite combative and superior from the first time I read it months ago, but I didn't say anything. Now somebody else has said the same thing, so clearly it's not just me.

---

<div class="post-metadata">

**Author:** ![zoecarver](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zoecarver/32/21535_2.png) [@zoecarver](https://forums.swift.org/u/zoecarver)\
**Post date:** [June 7, 2023, 6:46pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/24 "2023-06-07T18:46:52Z")

</div>

> we don't even bother introducing ideas such as memory lifetime management or signed integer overflows before making sweeping statements condemning C++ in favour of Swift.

The document is already 30+ pages. I don't think this document is the place to discuss the details of memory safety in C++. We can reference it as it pertains to C++ interop and let other documents (such as the one Puyan mentioned above) go into the issue in depth.

> [@Karl](#):
>
> I think it would make the document more approachable if it were based on those kinds of specifics rather than sweeping generalisations.

It's not sweeping generalisations. We call out specific patterns that create specific problems for bridging. Then we aggregate all of those patterns/problems together in summary.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [June 7, 2023, 10:21pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/25 "2023-06-07T22:21:12Z")

</div>

> [@John\_McCall](#):
>
> ` __shared` and `__ consuming` have been formalized into the language as `borrowing` and `consuming`.

yes, i’m aware of that and it’s obviously a huge step forward! i’m just repeating things that have been communicated to me in the past when advocating for swift to provide context for how some C++ developers i work with perceive swift.

---

<div class="post-metadata">

**Author:** ![rwessel](https://avatars.discourse-cdn.com/v4/letter/r/c6cbf5/32.png) [@rwessel](https://forums.swift.org/u/rwessel)\
**Post date:** [June 11, 2023, 9:25pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/26 "2023-06-11T21:25:31Z")

</div>

> [@zoecarver](#):
>
> Taking this point of view means that Swift (and its tradeoffs) are framed as the ideal or the thing that we are trying to move towards. We necessarily need to juxtapose Swift with C++ when determining if and how to import APIs. So we need to 1) frame Swift as the thing we are trying to move towards and 2) highlight C++'s shortcomings when attempting to accomplish that.

The necessity to juxtapose languages and highlight relevant differences is not in question. It's the moment that you start to use words like "shortcomings" that readers might roll their eyes and think, "Oh God, yet another language fan-boy project" and move on. I almost did, but I'm glad I persisted because I think it has real merit.

C++ is designed to cope with a wide variety of contexts. It's important to understand these features before using them and - in particular - to understand in which context they are relevant. On that basis, C++ can be absolutely robust for resource management (including memory).

The features that are unsafe are there for a reason, i.e. they are not a mistake – you cannot do everything C++ does if those features are removed. But some features are intended for very narrow contexts.

The same is true of Swift. Putting on my Rust hat, I could just as easily write, "_Swift's lack of memory safety is a major defect. Full stop. This is not a subjective statement_." For a novice, Swift is unquestionably _safer_ than C++, but it isn't _memory safe_ (in the way Rust is). It's trivial to introduce ruinous memory leaks in Swift using standard language features (e.g. cyclic references).

But I feel this kind of statement (for both C++ and Swift) misses the point - absolute memory safety is not the objective for either. The feature set for both languages have specific development contexts and users in mind, i.e. their respective features exist by design not as an error or oversight.

> [@zoecarver](#):
>
> The point is that C++ exposes lots of mutable references and in large, complex codebases it is hard to keep track of everything.

That's a much bigger problem in Swift – it has no mutability controls for references to class instances (or for class member functions) whatsoever. Every reference is a mutable reference and every class function is a mutating function, which means it's much easier to write the buggy example in the documentation in Swift than it is in C++, e.g.:

```swift
class Foo {
	var bar = [Int]()
	
	func append(_ other: Foo) {
		bar.append(contentsOf: other.bar)
	}
}

func append_n_times(first: Foo, second: Foo, times: Int) {
	for _ in 0..<times {
		first.append(second)
	}
}

```

Why bother making this kind of case? Can't the docs simply say something alongs the lines of, "not everything in C++ is appropriate for consumption in Swift - we support _these_ features and not _those_. I've read many docs for bridging solutions like this and none them stray into criticisms like this one - I feel you are far more likely to attract a broader audience if you can take a neutral stance.

---

<div class="post-metadata">

**Author:** ![zoecarver](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zoecarver/32/21535_2.png) [@zoecarver](https://forums.swift.org/u/zoecarver)\
**Post date:** [June 11, 2023, 11:50pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/27 "2023-06-11T23:50:27Z")

</div>

It seems like your concerns are mostly around the presentation of the ideas in the document and less about the ideas themselves. If you have thoughts on the actual content, I would love to hear them. I think a discussion about our goals for importing C++ APIs or the concrete approach for importing C++ APIs would be productive and beneficial to the project.

I appreciate your concerns about how the content in the document is presented, but it may be a bit late to change at this point. We want to evolve interop over time based on feedback from our adopers and the community, so we can certainly evolve our approach for import C++ APIs over time. But I don't think it will be productive to change the details of how that approach (and goals) are presented in the vision document, especially if there is no substantial change to the content, and especially given that the LWG has already approved it. This document has been under review from the community for the better part of a year, so it would have been great to hear this feedback earlier. That being said, if you are really concerned about how the content is presented in the document, maybe you can put up a PR and we can discuss the concrete changes further over there. (I don't know what the processes for editing accepted vision documents is, it may not be possible to change the document at this point.)

---

<div class="post-metadata">

**Author:** ![Nikolozi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nikolozi/32/8305_2.png) [@Nikolozi](https://forums.swift.org/u/Nikolozi)\
**Post date:** [June 12, 2023, 7:26am UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/28 "2023-06-12T07:26:24Z")

</div>

Where's the best place to discuss and ask questions about the C++ interop? Would that be the `Using Swift` or `Development > C++ interoperability` area?

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 12, 2023, 12:47pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/29 "2023-06-12T12:47:37Z")

</div>

Either Evolution \> Discussion or Using Swift. Development is generally for discussing the implementation of the compiler/library.

---

<div class="post-metadata">

**Author:** ![rwessel](https://avatars.discourse-cdn.com/v4/letter/r/c6cbf5/32.png) [@rwessel](https://forums.swift.org/u/rwessel)\
**Post date:** [June 20, 2023, 8:28am UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/30 "2023-06-20T08:28:10Z")

</div>

> [@zoecarver](#):
>
> It seems like your concerns are mostly around the presentation of the ideas in the document and less about the ideas themselves. If you have thoughts on the actual content, I would love to hear them

Yes, absolutely. A project with a poor vision statement isn't off to a good start. It was the first thing I read (and others will read) so it matters.

And yes, I'd like to get further into the nitty-gritty of the content. I'm working on a large project that already combines C++ and Swift, but the bridging is less than ideal at the moment. This project looks like a better way forward.

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [June 26, 2023, 8:41pm UTC](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274/31 "2023-06-26T20:41:02Z")

</div>

> [@Karl](#):
>
> To be specific, I think we should include this summary [from swift.org](https://www.swift.org/about/) at the beginning proposal:

The Language Steering Group talked about this suggestion last week.

On the one hand, you're right that the document could stand to be a little more approachable to C++ programmers who don't know much about Swift. Given all the ways links get shared, it's not unimaginable that this interop vision will sometimes be the first thing that people see.

On the other hand, we don't want to put an ersatz introduction to Swift in every document that might serve a secondary outreach function like this. It seems better to just add a short paragraph to the introduction that explains that this document assumes a certain degree of familiarity with Swift and links to some appropriate page on [swift.org](http://swift.org).

Do you have any opinions about that?

[Previous page](https://forums.swift.org/t/accepted-a-vision-for-using-c-from-swift/65274.md?page=1)