So, for those developers living under a rock for the past 2 weeks, Apple introduced their new programming language Swift. They stated that the language has been in development for 4 years, so it is safe to assume that the language’s definition is fairly stable. Since I wrote several posts on what Objective C can learn from java, such as this most recent one, along with what it has learned, I should at least look at Swift. I have not yet actually programmed anything yet in Swift, but I have read through it’s documentation. If I got anything wrong in this post, call me on it.
First, the good changes.
Improvements
- Objects not pointers: In dealing with Objects instead of pointers, programmers should be less likely to produce memory access errors. This is overall a much safer language construct.
- Optional: Swift’s extensive use of optional types means that not only is delegate code simpler, it is also safer. Furthermore, this construct is extended to weak references, making them safer as well.
- Protocol/Class Namespace: While I never complained about it, Obj-C’s protocols and classes occupied separate namespaces. This meant that the syntax for addressing these was different. In Swift, the namespaces are the same, and a common syntax is use to reference a class or protocol. This does mean you can’t have a class and protocol with the same name, but I feel this is a small price to pay for simplicity of simply referring to a type rather than a class or protocol.
- Stronger Types: In spite of it’s automatic typing, the types in Swift are enforced more strongly than in Obj-C. This is deceptive because the use of var would seem to indicate a weakly typed language, when it is simply inferring the type from the usage. Of course, one can be explicit on the variable type.
- Let: When I read what let did, it simply struck me as it is behaving in the same manner as final in Java. It goes a bit further in that a dictionary or array that is declared in a let statement is also immutable. The same can be said for structs. This is a nice improvement.
- Single Source File: I mentioned this one in what Obj-C can learn. I’m glad to see that swift learned it.
- Generics: I haven’t looked at the full extent of their power in Swift, but I love having generics in Java. At a first glance, Swift seems to be just as powerful.
- Inner Classes: For those who’ve never used them, this is a powerful language feature. I use these all the time in Java.
- Override: Those familiar with Java know the annotation @Override which indicates the intent to override a super-class’s method. If the super-class’s method is not present, this annotation turns into an error, but the annotation is not required. Swift goes a step further by requiring override to override a super-class’s method. This is a great improvement.
- Closures: While blocks were technically a type of closure, Swift brings more power to them. Good addition.
Deficiencies
- Private Methods/Variables: This one I do not understand. Obj-C had private methods and variables but Swift seems to have nothing of the sort. If it were hard to enforce at run-time, I could understand enforcing at compile-time for now, but why is it completely missing? When constructing a class, there seems to be no way to indicate which functions/variables other classes can touch, and which they cannot. The best means seems to be to use protocols instead of the concrete classes. For a library author, this is a complete nightmare. This is odd considering how Apple feels about calling private APIs in their libraries. I hope this is merely a temporary oversight and it is coming soon as this is a deal-breaker for many. There is hope that this is indeed the case.
Still MIA
- Abstract Classes: Combined with abstract methods, these are still missing. See my previous post for more details. Maybe when it gains access controls we will get this, but I’m not holding my breath.
- Namespaces: While it is possible to fake some namespace in Swift, it is no where near what’s truly needed. Again, seem my previous post for more details.
- Exceptions: Apple seems to be extremely strongly against checked exceptions and Swift has made this even worse. The language seems to be completely devoid of try-catch as well as finally and throw. This is problematic since it is supposed to be used along-side Obj-C code, which can throw. So if Swift calls a method that throws, it is wholly incapable of catching such exceptions or even cleanup in a finally block. Once again, the broken record says “See my previous post for more details.”
Conclusion
Swift is definitely a strong improvement over Obj-C. Unfortunately the lack of private eliminates it as a viable replacement in several situations. If Apple fixes this, the cases where one needs to use Obj-C are nearly eliminated. Perhaps we will get namespaces some day, but I would not expect abstract classes nor checked exceptions. Overall, good improvement Apple. Keep it up.