It also cannot challenge C for several reasons, including the fact that it's very slow at working with native types such as integers because it tries too hard to be safe.
What a stupid thing to say.
First of all because you are repeating things you heard whilst Swift was in beta. It got a lot faster. Comments were made based on non-optimised compilations.
Secondly, for most purposes being correct is far more important than being faster. We've had decades of experience of the bugs and security vulnerabilities that Cs unchecked nature gives.
Thirdly if you don't want the checks you just switch them off in the compiler options. The norm of course being to have more checks in debug builds than release builds.
And Fourthly, having a way to express more invariants to a compiler, such as whether or not a pointer can be nil, results in FASTER code because better optimisations can be done. e.g. For correct C code you very often need to write manual checks on whether a supplied pointer is nil. In Swift this is not normally necessary for the programmer nor the compiler to do.
If you have a link to some benchmarks of the released version of Swift vs C, with appropriate optimisations, then we can see if there's any truth in it for v1.0 of Swift. And even then we don't know how much faster Swift will get in future releases. It certainly isn't impossible for it to be faster than C. Your assumption is wrong.