Note: I’m going through draft posts that go back to 2014 and publishing where they still may have value. They may not be 100% upto date but better published late than never.

Introduction

Protocols can be thought of as similar to interfaces within languages such as C# and Java, hence are used to declare expectations for implementations and can be returned or accepted as params.

We declare a protocol in the following way

protocol Person {
  var firstName: String { get }
  var lastName: String { get }
  var age: Int { get }
}

So we can create our implementation of this procotol like this

struct PersonImpl : Person {
  var firstName: String
  var lastName: String
  var age: Int
}

Structs and Classes

Apple Swift developers seem to prefer value types over reference types, a struct is a value type and class a reference type. They both share many of the same functionality.

Structs do not require an initializer (constructor) as a default initializer is supplied automatically and will expect all non-optional properties to be supplied.

class PersonImpl : Person {
  var firstName: String
  var lastName: String
  var age: Int

  init(firstName: String, lastName: String, age: Int) {
    self.firstName = firstName
    self.lastName = lastName
    self.age = age
  }
}

As you can see, init is the name of the initializer or what we may view as a constructor. Classes may also have deinit is called when Swift deallocates an instance (struct’s do not have deinit).

Mutations

Where we expect changes to the internal data, in other words where a function mutates data we use the mutating keyword. If, for example, we add a protocol function

func incrementAge() -> Void // same as func incrementAge()

By default struct properties cannot be changed by instance method. In such cases we need to include the mutating key word, i.e.

mutating func incrementAge() -> Void

So a struct method implementation will now look like this

mutating func incrementAge() -> Void {
  age += 1
}

Within a class, we don’t need to mark the method as mutating.

Accessors

There are five access levels

• Open: This allows proprties, methods, classes etc. to be accessible by anything that imports the module
• Public: This allows proprties, methods, classes etc. to be accessible by anything that imports the module
• Internal: This is the default access level and allows properties, methods, classes etc. to be accessible from the module where they’re defined only
• Fileprivate: Properties and methods can access from code withint he same source file only
• Private: The least visible accessor meaning properties methods etc. are only visible within the same file or class etc.

is and as

Swift has the concept of is and as pretty much like C#. So we can declare a type as follows

let p: Person = PersonImp("Scooby", "Doo", "12")

Now if we needed to check if the const p is a PersonImpl we would use

if p is PersonImpl {    
}

we could use as within the if statement if we wanted as well, for example

if let person = p as? PersonImpl {    
}

Here we compare and assign in the same line of code using as? which basically means the person may be nil (if the type cannot be converted to PersonImpl).

Extensions

Just like extension classes in C# – Swift extensions allow us to add functionality to structures, protocols and classes (as well as enumerations).

An extension is defined using the extension key word, for example

extension String {
  // add string functionality, for example
  func capitalize() -> String {
    return self[0].toUpper() + self.substr(1)
  }
}

We can also add constraints to extensions, so for example a Collection extension that

extension Collection where Iterator.Element: Comparable {
  // add functionality where elements support Comparable
}

Equatable

A type needs to conform to the Equatable protocol for a type to be comparable using == and !=.

Generics

Swift generics look much the same as generics in C++, Java and C# in that we can declare generics on a function like this

func add<T>(item: T) {
}

We can also add constraints to the genric type like this

func compare<T: Comparable>(a: T, b: T) -> Bool {
}

Note: I’m going through draft posts that go back to 2014 and publishing where they still may have value. They may not be 100% upto date but better published late than never.

Generics are interesting within Swift. Syntactically they look the same as most other languages which supports generics. So, we have the syntax below

class Policy<TResult> {
}

Generic and non-generic types of the same name

In C# we can essentially create a generic and non generic type and the compiler works out which we meant to use. Sadly this doesn’t exist in Swift (or Java or maybe many other implementations). But then, rather interestingly we can (assuming no constraint on the generic parameter) actually create a generic of type Void, i.e.

class Test<TResult> {
  func run(_ action: () -> TResult) -> TResult {
    return action()
  }
}

and then write code like this

let a1 = Test<String>()
let a2 = a1.run({ return "Hello" })

let b1 = Test<Void>()
let b2 = b1.run({ return })

What about, if we looked at this problem from the perspective of creating a default type for the generic. Swift doesn’t support this but we can (sort of) create something like this using init. Where we take an argument of the generic type, so for example if we have

class Test<T> {
  init(value: T) {
  }
}

Okay so we can now declare our variables like this

let t1 = Test(value: 42)
let t2 = Test(value: "Hello")

I know, this doesn’t have a default implementation at all, so instead we’ll create an extension which does the defaulting for us

extension Test where T == Person {
    convenience init() {
        self.init(value: Person())
    }
}

Now we create an instance like this

let t3 = Test()

See Can I assign a default type to generic type T in Swift? for further information on this one.

Adding constraints

We can add a constraint, for example the generic type must a a type of Error, like this

class Test<TError: Error> {
}

We can also create constraints against properties of a type, for example at a function level we can check or (as above) on extensions using the where clause. So in the example

extension Test where T == Person {
}

The extension implicitly knows that there’s a generic parameter T and so we don’t need to redeclare it, instead we’re simply saying this extension works for Test where T is a Person. This sort of technique can also be used within functions.

Default value

If you come from a C# background, you’ll probably be used to using default(T) or the shortened version simply default. Swift doesn’t include such a keyword. Instead you’ll either need to use optionals, i.e. returned a .some or .none, or ofcourse you might create a function of class to imitate such functionality yourself.

Note: I’m going through draft posts that go back to 2014 and publishing where they still may have value. They may not be 100% upto date but better published late than never.

Swift comes with async/await syntax/functionality, however the support is dependent upon version of Swift and more importantly whether it’s the Mac (I’ll include iOS and watch OS in this) version of the Linux version.

Currently I’m playing with Swift on Linux and using the URLSession.shared.dataTask which is essentially a callback function. The URLSession.shared.data async/await version currently does not exist on Linux. So let’s create our own version and look at the process and ofcourse, how to use async/await (if you’ve used C#, TypeScript with async/await you’ll already know the basics of using the syntax).

Functions should be declared as async, so for example

func data(for request: URLRequest) async -> (Data, URLResponse) {
  // do something
}

Here’s an example of using the URLSession.shared.dataTask and declaring the code in an async method

#if canImport(FoundationNetworking)
public extension URLSession {
    func data(for request: URLRequest) async -> (Data, URLResponse) {
        await withCheckedContinuation { continuation in
            URLSession.shared.dataTask(with: request) { data, response, error in
                continuation.resume(returning: (data!, response!))
            }.resume()
        }
    }
}
#endif

Now, in usage, we can do this

let data = await URLSession.shared.data(for: request)

I’ve previously posted about structs and classes in Swift, let’s look a little more in depth into the subject

Differences between a struct and class

As you may know, structs use value semantics whilst classes use reference semantics. In other words if you do something like this

struct Point {
   var x: Double
   var y: Double
}

let pt1 = Point(x: 1, y: 10)
let pt2 = pt1

Your pt1.x, pt1.y values are copied to pt2.x, pt2.y. If you therefore alter p1 this does no affect p2. Swift using COW (copy on write) so this is more performant than one might think if you were making lots of copies – in other words the copying takes place only when a value is changed – so thing lazy copying of values.

Structs are stored on the stack and hence are very performant in terms of creation etc. Ofcourse if you’re making many changes to copies of a struct then things are less performant due to all the copying that needs to happen (even with COW).

Ofcourse, in a more complicated scenario, such as the Point also having a member variable which is a class, then these will be stored on the stack, but with references to the heap based classes. This is an issue for structs, if a struct contain multiple reference types it’ll incur reference counting for each reference type in the struct.

Classes on the other hand use reference semantics and therefore if we rewrite the about for a class. Then p2 is a reference to p1. Any changes to p1 will be reflected in p2

class Point {
   var x: Double
   var y: Double
}

let pt1 = Point(x: 1, y: 10)
let pt2 = pt1

Classes are stored on the heap which means that allocation will be les performant than a struct, but ofcourse if you’re passing around a reference to a class, this is more performant. However because a reference type copies the reference pointer it does ofcourse lend itself to issues around mutation of state and this becomes more of an issue when we add in concurrency.

The reference types use reference counting to handle auto-deletion (i.e. garbage collection). This does mean that a reference type will also require more space that a struct to track it’s reference counter. Also due to it using the heap, again potential concurrency issues means the OS must lock memory etc.

If you’re using String or the likes in a struct, you’re storing a reference type, hence this will incur reference counting overhead. If we’re using a String to ultimately represent known values, for example UP, DOWN, OUT_OF_SERVICE then not only will it be more type safe to use an enum, from a performance perspective this would be better, for example we can declare a status enum with a String type as a raw backing value like this

enum Status: String {
   case up = "UP"
   case down = "DOWN"
   case outOfService = "OUT_OF_SERVICE"
}