I feel this also misses the point.
I'm not arguing for one second that memory safety is not critical, or that Swift doesn't improve on C++ in some ways with regards to safety. I just think we're communicating that in a very blunt way -- 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. I think it would make the document more approachable if it were based on those kinds of specifics rather than sweeping generalisations.
I mean, to what extent is Swift even safe? IIRC, it's only "safe-by-default". The only thing stopping you from introducing the exact same memory safety failures as C++ is that some type names include the word "Unsafe" - and we have constantly retreated on even that tiny marker over time.
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++?
Recently, I mentioned that the custom actors executors proposal introduces a boatload of unsafe behaviours without ever mentioning the word "unsafe". Not a single change was made to the design. You can completely break memory safety if there's a bug in how you implement your actor or executor, leading to the same kinds of UB as in C/C++.
So we have to be honest about that, and starting the conversation by saying things like:
C++'s lack of memory safety is a major defect. Full stop. This is not a subjective statement.
is not helpful, and ignores the reality of what Swift can realistically do to improve on C++'s language model, and which compromises we have had to accept along this language's journey.