So what is the take-away when foundational types of the language that are classic examples of types that should be classes are implemented as structs? To me, it seems the API designers for Swift are already compensating for weaknesses in the language’s runtime and are trading supposed run-time performance over platform extensibility and that we, as developers of frameworks, should be doing the same.
SortedArray is perhaps a poor example, but I agree that there seems to be a code smell here. The more I learn about Swift, the more I see a, perhaps unavoidable, tension: Swift is (promised to be) faster, but Objective-C is more flexible. Swift doesn’t have much in the way of libraries, so it’s designed to work well with Objective-C’s, but there’s friction at this border.
What is the long-term plan? Keeping the frameworks all Objective-C would hold Swift back. But making pure Swift APIs would cut off access from Objective-C. Swift seems best-suited to lower level code where performance is more important than flexibility, i.e. the areas where Apple is now using C++ underneath an Objective-C API. But Apple is clearly pushing for its use on the other side of Objective-C, calling in.
Stay up-to-date by subscribing to the Comments RSS Feed for this post.