There is really no chance that OS X will be re-written in Swift ever. Swift is an application language and C is a system language. Both are proper tools for the spaces they occupy. Just because not every line of code is not at the most optimized state doesn't make it bad. Clarity of code has its value in terms of readability, maintainability, and correctness. Optimization should only override those aspects as needed. Yes you could try to optimize every piece of code, but likely it will not be released in your lifetime, and will defy any attempts to extend and update it after the original coders have moved on.
Apple describes Swift as "the first industrial-quality
systems programming language that is as expressive and enjoyable as a scripting language." To also quote Stephen Canon, "If Swift is to be a systems language someday, then we also need to be able to write (parts of) Accelerate in Swift." So yes, there is a chance that core frameworks of OS X will be re-written in Swift someday.
I'm not saying clarify of code isn't important or that every line of code in a program needs to be optimised. The other loop already exists and people are free to use it. But they are
removing the fast one. The language should not prevent you from optimising a piece of code because they
force you to use slow loops that are 'prettier'. I am saying that when designing a
systems programming language, performance should be a more important than whether a line of code "feels nicer" than another when they are arguably equivalent on a readability level.We have enough slow languages with plenty of clarity that are easier than asm/C/C++ (like Python). I want one (like Rust
but with better integration) with clarify
and the performance of C/C++.