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.
2 Likes
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).
9 Likes
To be specific, I think we should include this summary from swift.org 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 anilobject 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 wherenilis appropriate, and for these situations Swift has an innovative feature known as optionals. An optional may containnil, 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.
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.
3 Likes
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.
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.
4 Likes
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.
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.
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.:
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.
5 Likes
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.)
3 Likes
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?
2 Likes
Either Evolution > Discussion or Using Swift. Development is generally for discussing the implementation of the compiler/library.
3 Likes
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.
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.
Do you have any opinions about that?
4 Likes