The current draft of the document "Using C++ from Swift" often strays into 'language wars' territory. It would be far more effective if it simply discussed the philosophy for adapting C++ to Swift without discussing the pros and cons of each language. It's particularly bad in this case because it makes a number of assertions about C++ that are only partially true and creates "straw man" arguments that any C++ programmer would recognise in an instant. In addition to putting off programmers considering using Swift, it makes it look as if the author has a poor grasp of the language.
Consider the code in the Mutability section for example. Only someone with a poor grasp of C++ would write code like that. If the intention was to pass a value to append to an object passed by reference 'n' times, why not simply pass the string to be appended as a value rather than a reference? And if the appended object was potentially expensive to pass as a value, anything working on two references would check that the input parameters weren't at the same address (and respond accordingly). Moreover, Swift has exactly the same problem - consider what happens if you write the same function with references to 2 instances of the same class rather than a struct. You might say, "but you shouldn't do that!", but that's exactly my point about the C++ example.
And memory management? The fact is, you can come completely unstuck with Swift too (and very easily). It's a matter of understanding what you're doing. C++ simply gives you choice about resource management:
- It can be all manual
- It can be reference-counted (exactly like Swift if you choose)
- It can be a custom allocator (including garbage collection if that floats your boat)
- It can avoid all dynamic heap allocation
- … and so on.
Swift makes it easier by removing those choices - for most App developers, that's a very good thing. But C++ provides those choices for programmers who need them, and that's fine too. You're wasting your breath encouraging them to use Swift in those contexts because it isn't appropriate for that job.
Everyone should accept that all programming languages exist for a reason - just pick the language that best suits the context. I've work extensively with many languages (including Swift and C++) and I like them all - but just for different purposes. It's really grating to see deprecations made about C++ in this document, and I feel it would be much improved by just sticking to interoperability without judgement.