Swift is a new programming language created by Apple with a couple of interesting programming paradigms and differences to the big established languages. Like Objective-C Swift is created for iOS, OS X and watchOS development und should be a safer, faster and more powerful alternative to Objective-C.

StackoverflowStatistics

Source: StackOverflow: http://stackoverflow.com/research/developer-survey-2015

Like shown in the survey 2015 from StackOverflow Swift has already gained great popularity.

 

Overview

Swift is a multi-paradigm language which follows object oriented (Java, C#), functional (Haskell, Standard ML), imperative (C, C++, Objective-C) paradigms and elements from script languages (Python, Scala). Chris Lattner, the creator of the language, himself says “from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list.”[1] It offers inheritance, type inference, generic programming, closure, multiple return values, etc. In this post we will have a look at the most interesting differences and features.

 

Performance

According to the presentation of Swift 2.0 at the WWDC 2015 (annual Apple Worldwide Developer conference) Swift is supposed to be a lot faster than Objective-C:

SwiftVsObjectiveC

Source: Apple: https://developer.apple.com/videos/wwdc/2015/?id=409

This results out of more and better compiler optimizations.

 

SwiftVsCBenchmark

Source: Primate Labs: http://www.primatelabs.com/blog/2015/02/swift-performance-updated/

Let’s compare Swift to C++. According to the benchmarks from Primate Labs Swift has approximately the same average performance as C++ except in the GEMM test, where C++ is still about 4.5 times faster.
Note: This test was made with Xcode 6.1.1 Beta 3. The latest version right now is Xcode 7 Beta 4 (Aug. 2015).

 

Getting Started:

To get started, visit this website https://developer.apple.com/swift/resources/. From there you get a lot of code samples, projects and tutorials. Additionally you can read all “The Swift Programming Language *” books for free, which are complete guides through the language.

 

Hello, world!

Let’s follow the tradition and have a look at the “Hello World” program:

Swift:

Java:

Objective-C:

As you can obviously see, it’s a lot more code in Java and Objective-C than in Swift. This single line in Swift tells us a lot: Swift doesn’t need a main function and semicolons at the end of expressions and works also like a script language. If we only want to do something simple like this print statement, languages like Java produce an overhead, because we are forced to create a class. By the way, print is a global function in Swift and fortunately we don’t need the @-notation for strings anymore.

 

Type inference

Swift

Java

Objective-C

Whereas we always have to declare the type of variables in Java or Objective-C, we don’t have to in Swift. The compiler calculates the type through type inference. Like in the example ‘a’ is implicit of type Double. Without the Int keyword, ‘e’ would have been implicit of type Int, because we assign ‘e’ with an Int value.

The equivalent of ‘final’ in Java or ‘const’ in Objective-C is ‘let’ in Swift. IMHO[2] ‘fin’ or ‘con’ would have been more intuitive.

Furthermore we always have to cast the types in Swift. The marked line would cause a compiler error, because ‘e’ is not of type ‘Int’. Whereas we can use in Java and Objective-C the implicit cast.

 

Multiple return values and tuples

Swift

Standard ML

There are no real equivalents to tuples or multiple return values in Java, Objective-C or JavaScript, but Standard ML supports all of these elements and IMHO you can see, that Swift has a lot in common with SML. You would have to return an extra type or array in Java or Objective-C, but often you would cause an overhead to create an extra class for these few properties and in an array the elements must be of the same type. You could also return a tuple in Swift or SML of complete different types (sugar: Double, milk: Int, others: String).

SML supports an even more complete type inference, so that we can rewrite the procedure ‘calculateMinMaxSum’:

without any explicit named types and the type of the procedure still is: val calculateMinMaxSum = fn : int * int -> int * int * int. The reason Swift doesn’t go that far has probably something to do with features like subtyping and overloading, which doesn’t exist in SML and makes it really hard for the language design, compiler and the awareness of the developer.

Maybe you recognized that in the Swift example the second parameter in the ‘calculateMinMaxSum’ call was labeled with ‘b’ like the parameter in the function and the first parameter isn’t labeled.  That’s because you have to label all parameters after the first one like in the function and the compiler even returns an error if you label the first parameter. This is an interesting syntax and can make the developer aware of the function’s parameters, but also leads to more code and IDEs could help at this point out.

 

Strings:

Swift

Java

Objective-C

One amazing new feature is, that Swift has a full Unicode support. Like shown in the example above you can directly declare the value “DOG FACE” from the Unicode set. In contrast to Java or Objective-C, where we have to to use the Unicode identifier. On top of that you could declare a variable named liked the dog smiley “let 🐶😸😱😉 = 5″. This is a big advantage for developer who have to handle a lot with non-usual Unicode characters and exotic languages. It can also lead to illegible code for non-native speakers, if someone doesn’t pay attention to the international standards.

Usual operations like string concatenation was annoying in Objective-C, if you are used to a ‘+’ operator for Strings. The more elegant approach in Objective-C was to use the stringWithFormat function, using string interpolation, but it isn’t really equivalent to the Swift example. We used in the Swift example the string concatenation operator ‘+’ and string interpolation. So the ugly approach from the Objective-C example is more equivalent to the ‘+’ operator and you can see how messy it is.

At this point you can also recognize that Swift uses the dot notation like in Java and not the SmallTalk like syntax.

 

Class, Structs and Protocols

Swift

Java

Objective-C

Let’s have a look at the cornerstone of the OOP world. Swift has the concept of classes and structs. The classes are equivalent to Java’s classes or Objective-C’s interfaces. The behavior is all the same in Swift, Java and Objective-C. We create an object ‘aClass’ while ‘bClass’ and references ‘aClass’. Afterwards we change ‘favLang’ to “Swift”. ‘aClass’ and ‘bClass’ just show to the same point in the memory. Thus classes are reference types.

Structs in Swift act different to classes and structs from Objective-C/ C/ C++.

Structures support many of the same behaviors as classes, including methods and initializers. One of the most important differences between structures and classes is that structures are always copied when they are passed around in your code, but classes are passed by reference. [3]

The Swift struct’s example prints at first “Assembler” and then “Swift”, because ‘bStruct’ doesn’t hold a pointer to the same memory address, all values are copied and with the statement “aClass.favLang = “Swift”” only the value of  ‘aStruct’ changes. Consequently structs are value types.

There are some big differences between these three languages as we can see in the examples. Swift:

  • doesn’t use header files (like Java)
  • supports structs but act as value types
  • has a constructor called ‘init’ (Objective-C doesn’t have constructors)
  • forces the developer to name parameters in a constructor call (Line 30). IMHO that seems inconsistent to me, because Swift forces the developer not to label the first parameter in a method call.

Swift also supports inheritance and protocols aka. interfaces.

 

Functions and Closures

Swift

Standard ML

Welcome to the functional world! And again Swift and Standard ML look pretty similar. The variable ‘increment’ itself is a function, because ‘makeIncrementer’ returns the inner function ‘addOne’ of type ‘int -> int’. It takes an argument of type int and returns an argument of type int. This concept ist called closure. It doesn’t exist in Objective-C and is only available in Java since version 8:

 

Switches and Patterns

Swift

Java

How sweet the syntactic sugar is! Swift’s switch supports tuples and on top of that we can create pattern to match the right properties. ‘let x’ is a wildcard and puts the value in the constant ‘x’, whereas in Java we need an extra line for the assignment (line 21). The range operators ‘…’ (includes both values) and ‘..<‘ (omits its upper value) makes the code clear and easy to understand, whereas in Java we need 4 checks. Even in the switch statement we can check for further properties with ‘where’. These kind of checks are not possible in neither in Java nor in Objective-C. This is even true if we would check on a single Integer in a switch statement. We couldn’t easily write “case x == 5 % x:”

The pattern matching and the range operators are great new features, which improves the tidiness and understanding in the code.

Note: There is no real tuple equivalent in Java, but to demonstrate the clarity in the Swift’s example, the tuple was realized with a private class.

 

Optional Values

The concept of optionals doesn’t exist in C or Objective-C. The nearest thing in Objective-C is the ability to return nil from a method that would otherwise return an object, with nil meaning “the absence of a valid object.” However, this only works for objects—it doesn’t work for structures, basic C types, or enumeration values. For these types, Objective-C methods typically return a special value (such as NSNotFound) to indicate the absence of a value. This approach assumes that the method’s caller knows there is a special value to test against and remembers to check for it. Swift’s optionals let you indicate the absence of a value for any type at all, without the need for special constants. [4]

Swift – Optional#1

Optional values are a profound concept in Swift, therefore we will take a detailed look. Here we go:
The Int() initializer returns an optional value, because it is not guaranteed that the passed parameter is correct. The != and == operators are overloaded and implicitly compare the unwrapped value of  ‘convertedNumber’. To the contrary to Java or Objective-C even primitive datatypes can have the value ‘nil’. Hence ‘possibleNumber’ was a legitimate argument, ‘convertedNumber’ is not nil. The prints are above. The exclamation mark unwraps the value. That’s the reason why the output is:
convertedNumber value: Optional(123)
convertedNumber value: 123 (Without “Optional” because the !-operator unwrapped the variable)

 

Swift – Optional#2

The variables a, b, c, d and f show us the three options: optional variables (‘?’), normal variables and implicitly unwrapped optional variables (‘!’). The first print prints similar to the example before “Optional(value)” because the variable is optional and not unwrapped. ‘c’ acts like a optional value and we can pass optional values (like we do with ‘f’), but the value is always implicitly unwrapped. ‘e’ is a normal value, therefore we cannot pass an optional value and have to unwrap ‘Int(possibleNumber)’ with an exclamation mark. That’s also the reason why we are not allowed to unwrap ‘e’ (line 18). We can unwrap ‘f’ but it has no effect and the print would have been the same without exclamation mark.

Swift – Optional#3

Now, it’s getting interesting. ‘g’ is an implicitly unwrapped optional value. ‘Int(noNumber)’ returns ‘Optional(nil)’ because the baby chicken is unfortunately not a proper number. ‘g’ implicitly unwraps the value and ‘nil’ is first printed. The next line causes an error because we try to unwrap a value which was never set.

Now an example, where optionals are a great advantage:

Swift

Java

This problem is called Pyramid of doom and leads in many languages to confusing code. Optional chaining in Swift solves this problem in one line and looks quite elegant.

Let’s face the other side of the coin:

What’s the output? It’s not that easy:

The upper example shows that optional values make code very complex. “3” and “4” are printed because “==” and “!=” are overloaded and unwrap the optional implicitly. Additionally the negating exclamation mark in combination with the unwrapping operator leads to confusing code.

For the sake of completeness it has to be added that since version 8 Optionals also exist in Java, but there are not really anchored and common yet. Also StandardML supports Optionals.

IMHO: Are optional values blessing or curse in Swift? Personally I think that optional values make the code too complex and distract from the actual logic. I don’t see a big advantage to hazard the disadvantages. Optional chaining (Swift) without optionals like in C#’s null propagation would have been the best compromise.

 

Conclusion

Swift brings some great features like simple String operations, full Unicode support, functional elements combined with object oriented elements, tuples and extended pattern matching. I’m glad that Swift uses the dot notation instead the SmallTalk syntax like in Objective-C. Compared to Objective-C the code appeals cleaner. It seems that Apple wanted to establish a beginner friendly programming language. I don’t feel convinced of the optional value concept, but I’m curious to see how the concept will hold up in larger projects in the future. Also allowing the developer to omit the type can increase the potential of error. What’s your impression? Leave a comment what your opinion is!

 

Sources:

[1] http://nondot.org/sabre/

[2] IMHO = In My Humble Opinion

[3] Apple: The Swift Programming Language (Swift 2 Prerelease) Page 31

[4] Apple: The Swift Programming Language (Swift 2 Prerelease) Page 73

 

Update 6th Oct. 2015: Added a Java closure example and complemented the Optionals part.

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close