Milen's Writings

Swift Unsafe Pointers

Sun, 06 Nov 2016 00:00:00 +0000

Swift 3 has several different pointer-like types that allow interfacing with the outside world. This article provides a concise overview of UnsafeRawPointer, UnsafePointer, AutoreleasingUnsafeMutablePointer, Unmanaged and OpaquePointer.

Note that UnsafeRawPointer and UnsafePointer have mutable variants, namely UnsafeMutableRawPointer and UnsafeMutablePointer. I'll refer to both variants using the shorter names and clarify as required.

In Swift 3, the pointer types now represent non-nullable pointers (UnsafePointer, UnsafeMutablePointer, AutoreleasingUnsafeMutablePointer, OpaquePointer, Selector and NSZone). This means you don't have to check whether they are nil as nullability is expressed via the type system using optionals. This allows the preservation of nullability annotations when interacting with legacy APIs.

UnsafeRawPointer

UnsafeRawPointer represents a untyped pointer (void*) and is declared as a struct:

public struct UnsafeRawPointer : Strideable, Hashable {
  // ... more code ...
  
  public func distance(to x: UnsafeRawPointer) -> Int
  public func advanced(by n: Int) -> UnsafeRawPointer
}

UnsafePointer

UnsafePointer represents a typed pointer. It's declared as a generic struct. Here's the mutable variant:

public struct UnsafeMutablePointer<Pointee> : Strideable, Hashable {
  // ... more code ...
  
  public var pointee: Pointee { get nonmutating set }
  
  public static func allocate(capacity count: Int) -> UnsafeMutablePointer<Pointee>
  public func deallocate(capacity: Int)
  
  public func initialize(to newValue: Pointee, count: Int = default)
  public func deinitialize(count: Int = default) -> UnsafeMutableRawPointer
}

Memory State

The memory referenced by an UnsafeMutablePointer can be in one of the following states:

Deallocated.
Allocated but not initialised.
Allocated and initialised.

It's only safe to use the pointee property if and only if the memory is allocated and initialised. This means you have to call allocate(), initialize(), deinitialize() and deallocate() in the correct order.

// Allocate storage on the heap for UInt64 (8 bytes) and point to it
let uint64Pointer = UnsafeMutablePointer<UInt64>.allocate(capacity: 1)

// The memory state is undefined, so before using the pointee property, it must be initialised
uint64Pointer.initialize(to: 0xAABBCCDD)
print("int value: " + String(format:"%X", uint64Pointer.pointee)) // prints AABBCCDD

// Treat the pointer as a pointer to UInt8
uint64Pointer.withMemoryRebound(to: UInt8.self, capacity: 1) { (byte: UnsafeMutablePointer<UInt8>) in
  // When executing on a little endian machine, it will print DD,CC,BB,AA
  // On big endian, it will print AA,BB,CC,DD
  print("first byte value: " + String(format:"%2X", byte.pointee))
  print("second byte value: " + String(format:"%2X", byte.advanced(by: 1).pointee))
  print("third byte value: " + String(format:"%2X", byte.advanced(by: 2).pointee))
  print("fourth byte value: " + String(format:"%2X", byte.advanced(by: 3).pointee))
}

uint64Pointer.deinitialize(count: 1)

// `pointee` should not be used after being deinitialised
// `uint64Pointer` can now be re-initialised

uint64Pointer.deallocate(capacity: 1)

// `uint64Pointer` cannot be used anymore

Pointers to Reference Types

It's important to realise that when UnsafePointer is used with reference types, it does not in fact point to an object but rather, it points to a managed reference (which itself points to an object). Reference type lvalues represent managed pointers which perform reference counting, so the storage of let x: NSObject translates to NSObject *x. Consequently, UnsafeMutablePointer<NSObject> can be thought of as pointing to a var x: NSObject and assigning through pointee is equivalent to assigning to var x (i.e., referencing counting will be performed). Let's illustrate with some code.

// Allocate storage for `var x: NSObject` (NSObject *x), the memory state is undefined
let objVarPointer = UnsafeMutablePointer<NSObject>.allocate(capacity: 1)

// Set the initial value to a new NSObject, equivalent to `var x = NSObject()`.
// Underneath, it's equivalent to the following pseudocode:
//   x = obj
//   retain(x)
objVarPointer.initialize(to: NSObject())
print("\(objVarPointer.pointee.description)")

// Assign another obj, equivalent to `x = NSObject()`.
// Underneath, it's equivalent to the following pseudocode:
//   release(x)
//   x = obj
//   retain(x)
objVarPointer.pointee = NSObject()
print("\(objVarPointer.pointee.description)")

// It's crucial to de-initialise ref type pointers. Underneath, equivalent to:
//   release(x)
objVarPointer.deinitialize(count: 1)

// Deallocate storage for the managed reference
objVarPointer.deallocate(capacity: 1)

AutoreleasingUnsafeMutablePointer

AutoreleasingUnsafeMutablePointer is a typed pointer to references and it must point to storage that does not own the referenced object. By contrast, UnsafeMutablePointer assumes the referenced storage owns a ref count to the referenced object.

Unmanaged

Unmanaged represents an unmanaged reference to an instance of a particular type. It is declared as a generic struct restricted to reference types. Its job is to facilitative the conversion from unmanaged to managed references and vice versa.

public struct Unmanaged<Instance : AnyObject> {
  // ... more code ...
  
  public static func passRetained(_ value: Instance) -> Unmanaged<Instance>
  public static func passUnretained(_ value: Instance) -> Unmanaged<Instance>
    
  public func takeUnretainedValue() -> Instance
  public func takeRetainedValue() -> Instance
  
  public static func fromOpaque(_ value: UnsafeRawPointer) -> Unmanaged<Instance>
  public func toOpaque() -> UnsafeMutableRawPointer
}

If you receive an unmanaged CFType reference from an unannotated API, you can convert it to a managed one using the take family of methods. Use takeUnretainedValue() when you're not responsible for releasing the instance (those usually come from Get family of functions). Use takeRetainedValue() when you're responsible for releasing the instance (those usually come from Copy or Create family of functions).

To go in the other direction, use the take pass family of methods. If there's an unannotated CFType API which expects to receive a +1 reference, you need to use passRetained(). Note that the receiver of the unmanaged reference is responsible for balancing the +1, otherwise the object will leak. Most of time, you need to use passUnretained() when interacting with APIs which expect a +0 reference.

Finally, fromOpaque() and toOpaque() allow you to convert between raw pointers (i.e., void* pointers) and Unmanaged references.

OpaquePointer

OpaquePointer is used for C pointers that cannot be represented in Swift (e.g., pointers to incomplete struct types). There's very little you can do with this type: it can be created, compared and debug logged.

← Back to Writings

References

The Mac Platform Decline

Sun, 30 Oct 2016 00:00:00 +0100

David Owens II:

To me, Thursday’s event signaled one thing for me, and maybe I’m completely wrong, but the Mac is officially over.

Apple, the MacBook Pro is not a pro-level computer. It’s simply not.

Ted Landau:

Apple’s desktop Mac lineup is headed for the graveyard. Dead. Done. Over.

It has taken me some time to collect my thoughts on the state of the Mac platform. My feelings have been developing over several years and I think after the October 2016 event, it's time to put them in writing. It's fair to say that I've gone through the five stages of grief: denial, anger, bargaining, depression, acceptance.

hello again

At the October 2016 event, Apple announced updated models of the MacBook Pro line while desktop Macs did not even get a single mention. At the time of writing, desktops have not been updated in at least a year.

iMac: Last updated 382 days ago
Mac Mini: Last updated 744 days ago
Mac Pro: Last updated 1045 days ago

Pro for Professional?

From where I'm standing, Apple are redefining (shrinking) their target audience for the Mac platform. If you feel left out by the latest updates and the neglect on the desktop, it's simple as Apple deciding not to serve your segment's needs. I know that it can feel quite personal to Mac devotees, like me, but it's simply business and strategy.

If we look purely at the revenue split, the Mac accounts for about 10% of Apple's revenues. It's entirely plausible that a decision was made not to invest in a declining ecosystem which does not represent the future in Apple's mind. I'm not judging whether it's logical or it makes sense to do that, I'm just making it clear that such a scenario, which would reflect the reality we're seeing, seems possible.

Tim Cook's thoughts on computers are clearly expressed in this interview:

I think if you’re looking at a PC, why would you buy a PC anymore? No really, why would you buy one? Yes, the iPad Pro is a replacement for a notebook or a desktop for many, many people. They will start using it and conclude they no longer need to use anything else, other than their phones.

Yes, absolutely: the iPad Pro can and has replaced many people's computers, including Macs. But in the near term, it simply cannot replace it for a small minority with genuine high-end needs.

Outdated Hardware

Let me address the following point: Who needs anything more than a MacBook Pro? The answer is a very small segment of high-demanding users. Those are the people who have been waiting for a very long time to only be disappointed by the October 2016 event. Activities include heavy 2D / 3D post-processing, video editors, highly-demanding software development. While the base performance of laptops continuously improves to cover more use cases, some highly specialised workloads still require significantly more power.

I'm currently using a 6-core Mac Pro (2013) with 64GB of RAM. I'm developing code on a huge codebase and running a lot of demanding apps. I run out of memory on a regular basis and have the CPUs at very high utilisation throughout my work day. This workload is simply not possible on a laptop due to the thermal envelope (CPU-only TDPs of 130W vs 45W).

The Mac Pro is just embarrassingly outdated, still selling for the same price it did when it launched 3 years ago. The Xeon CPUs are 2 generations behind, the dual workstation-class GPUs are now significantly slower than a single high-end consumer Nvidia card. Brian Stucki notices:

Reminder: The current Mac Pro page brags about the performance with Aperture, a program that Apple retired 2+ years ago

Anecdotally, the people who need GPU perf now all use PCs: not because of the cost of Apple hardware but simply because the Mac Pro's GPU performance is not at all competitive. If we look at the fastest GPU configuration with a pair of workstation-class D700, this provides a total of 7 TFLOPS (3.5 TFLOPS per card). Over at the Nvidia camp, a single Quadro P6000 GPU has 12 TFLOPS, even the consumer Titan X Pascal can do 11 TFLOPS. So, a consumer Titan X Pascal is 57% faster than a dual D700. If you compare against dual Titan X Pascals, you would have a performance increase of 214%. For highly demanding GPU workflows, this sort of performance does matter.

After discussing the topic with a friend of mine, he remarked that he knows about a company who switched from an all-Mac setup to Linux and Windows machines in the span of a couple of years. For similar stories, you should visit some of the more prominent Mac Pro forums and see for yourself.

That's why professionals feel left out. As Jeff J. puts it:

Those complaining about Apple's current Mac lineup are not haters, they're lovers. They've spent 10+ years and 5+ figures on Macs.

The real kicker is that the ecosystem and platform where you might have invested 10+ years is suddenly disappearing from underneath you because you're not the target market anymore. On the software side, it seems that almost all updates are about feature integrations with iOS or collateral improvements from the shared base macOS and iOS share.

On the other side of the spectrum, we have the Mac Mini. To the uneducated observer, the Mac Mini might seem like a very unimportant product but it plays a crucial role in companies that develop Apple software at scale to provide continuous integration. For example, Facebook have clusters of Mac Minis that continuously compile and test their codebase. There are dedicated companies, like Macminicolo, whose sole job is colocating those small computers running macOS.

Last time Apple updated the Mac Mini, it took a big step backwards: it removed the quad-core i7 CPU option with only a dual-core option. This ended up reducing multicore CPU performance by almost 37% which represents a serious regression. From the outside, it seems that Apple just does not want to cater to those needs.

Tradeoffs

According to the October 2016 event, Apple's vision of the Mac future is just MacBook Pros: a one-size-fits-all approach. Apple has even left the standalone display business which provides further signal about their long-term plans.

This one-size approach has fundamental flaws because we haven't reached the stage where the tradeoffs are acceptable to high-demanding professionals. Almost every choice we make in this life is all about tradeoffs: it's the same in hardware engineering. For example, making laptops thinner and lighter means sacrificing performance that you wouldn't if you did not have those constraints .

But when you need all the power you can get, you don't care about thinness of your desktop, you have all the space you need. In this particular case, you should be able to pick a different set of constraints. And that's where one-size-fits-all simply does not work: you can't put a 12-core Xeon CPU, a Titan X and 64GB of RAM in a laptop package as thin as the MacBook Pro.

Once upon a time, those of us in the Apple ecosystem could choose between different sets of tradeoffs according to our needs. But increasingly, Apple is tuning the tradeoffs to casual consumer needs across its entire product line, leaving professionals out in the cold.

Professional Ecosystem

Here's the most important question: If professionals don't make Apple enough money to be worth targeting, why should they invest resources to support them and create products for them? If that's the case, then there's no point in professionals complaining because Apple is actively choosing not to cater to their needs. We could argue that Apple has done the maths and concluded that losing professionals and focusing on consumers would be a net positive. Professionals might disagree with this stance but it's an entirely logical and sensible position for Apple to take.

The counterargument that I'll make is that if you lose the professionals, you’ll lose a significant chunk of innovation and content that keeps consumers in the Apple ecosystem. Those professionals are content creators and if they use Macs at work, they're more likely to use Macs at home and create for Apple platforms. Professionals are influencers and affect the computing choices of their immediate family & friends.

A lot of the best indie Mac apps happened because their developers were Mac users before becoming programmers. You could say that macOS is currently the platform choice for a large part of the developer community, especially web developers. This creates a large ecosystem of people who are inclined to further develop the platform and create software for it. A big reason why consumers like Apple is because they used to benefit from the spillover from their professional-level tools.

Sentiment

Sentiment about Apple from professional users has become almost uniformly negative over the past few years. This gloomy attitude is also reflected in the regular conversations I have with engineers who develop for Apple's platforms. If Apple alienates developers to such a degree that they will no longer develop for its platforms in their free time, they'll have a very real long-term problem. Furthermore, developers act as evangelists for the platform. And let's not forget that the Mac sits at the bottom of the pyramid: all the iOS, watchOS and tvOS software gets created on the Mac. Neglecting the Mac platform will have a knock-on effect on the wider Apple ecosystem.

Another worrying aspect is the perceived health of the Mac ecosystem. If professionals feel that the platform is slowly dying and not catering to their needs, they have less of a reason to keep investing in it which eventually starts a vicious self-perpetuating spiral.

The Future

I don't want the professional Mac platform to die a slow death of neglect but that's where things seem to be going. The scary part is that the Mac community is unanimous in their characterisation of the situation. The trust in the ecosystem, its longevity, continued support and innovation seems to have been lost. Even if Apple were to release updated desktop hardware tomorrow, a big if, it will still not be enough to completely eliminate the mistrust.

For more on the subject, you should go and read Michael Tsai's excellent blog post. If you're into podcasts, listen to Accidental Tech Podcast: The Escape Zone (193).

I'd like to thank Nick Lockwood for his feedback on this article.

If history has taught us anything, it's that developers can make or break a platform. Nick Lockwood:

Here is what I imagine Apple's decline will look like: It won't be poor sales, or loss of revenue. It won't be a shiny new iPhone killer…

It will be a switch from iOS developers using Macs at home to them using PCs at home and having a "work Mac" for commercial development.

Most will still use iPhones, but they won't write apps for them except to make money. Their personal projects will be for Web or Windows.

All of the $70 indie apps that made Mac and iOS fun to develop on will dry up. The only apps will be social networking clients or F2P games.

And that's all. Apple will still be profitable, and consumers will still view it as the premium brand, but devs will favour other platforms.

← Back to Writings

There's diminishing returns as you keep making laptops thinner and lighter. You reach a point where the tradeoff is no longer worth it for the vast majority of people. You could also argue we have reached that point already: a lot of people complain about wanting better battery life rather than thinner laptops. ↩
Remember Xserve? ↩
In the UK, the Mac Pro price actually increased by £500 due to currency exchange rate adjustments. ↩
I believe that's Apple's thinking right now. It's not that they deliberately don't care about professionals, it's just that in their version of the future, it does not make financial sense to target the high-end professionals. ↩
The discontinuation of Aperture is another example of this direction. ↩
There's now a chicken-and-egg problem when it comes to investing in the Mac Pro line. Many professionals with high-end needs have already switched away from it due to poor hardware, leaving a smaller userbase. This is makes it increasingly harder to justify further investment. ↩

References

New MacBook Pros and the State of the Mac →

Live Photo API on iOS

Wed, 30 Dec 2015 00:00:00 +0000

What are Live Photos? From a marketing perspective, Live Photos record the moments just before and after you take a photo. Under the hood, a Live Photo is just a JPEG image together with a QuickTime file contaning an H.264 track.

Storing Live Photo Data

The first step in using Live Photos is to retrieve them and then access the underlying data. The easiest way to get hold of a Live Photo is to ask the user to select one from their camera roll. For this, we can use UIImagePickerController — the crucial part is including both kUTTypeLivePhoto and kUTTypeImage in the media types array.

@IBAction func showImagePicker(sender: UIButton) {
  let picker = UIImagePickerController()
  picker.delegate = self;
  picker.allowsEditing = false;
  picker.sourceType = .PhotoLibrary;
  picker.mediaTypes = [kUTTypeLivePhoto as String, kUTTypeImage as String];
  
  presentViewController(picker, animated: true, completion: nil);
}

Once the user has selected a photo, the delegate method will be called. From there we can check whether they have actually selected a Live Photo. If that's the case, we will generate a random directory where we can store all the associated resources. The PHAssetResourceManager gives us chunks of data which we concatenate. If we wanted to be more efficient, we could have used an NSOutputStream or NSFileHandle.

func imagePickerController(
  picker: UIImagePickerController,
  didFinishPickingMediaWithInfo info: [String : AnyObject]
) {
  guard
    let livePhoto = info[UIImagePickerControllerLivePhoto] as? PHLivePhoto,
    let photoDir = generateFolderForLivePhotoResources()
  else {
    return;
  }
  
  let assetResources = PHAssetResource.assetResourcesForLivePhoto(livePhoto)
  for resource in assetResources {
    let buffer = NSMutableData()
    PHAssetResourceManager.defaultManager().requestDataForAssetResource(
      resource,
      options: nil,
      dataReceivedHandler: { (chunk: NSData) -> Void in
        buffer.appendData(chunk)
      },
      completionHandler:saveAssetResource(resource, inDirectory: photoDir, buffer: buffer)
    )
  }
}

Once we finished collecting the data for a resource, we're ready to write it to a file. We get the preferred file extension and save the file to disk.

func saveAssetResource(
  resource: PHAssetResource,
  inDirectory: NSURL,
  buffer: NSMutableData)(maybeError: NSError?
) -> Void {
  guard maybeError == nil else {
    print("Could not request data for resource: \(resource), error: \(maybeError)")
    return
  }
  
  let maybeExt = UTTypeCopyPreferredTagWithClass(
    resource.uniformTypeIdentifier,
    kUTTagClassFilenameExtension
  )?.takeRetainedValue()
  
  guard let ext = maybeExt else {
    return
  }
  
  var fileUrl = inDirectory.URLByAppendingPathComponent(NSUUID().UUIDString)
  fileUrl = fileUrl.URLByAppendingPathExtension(ext as String)
  
  if(!buffer.writeToURL(fileUrl, atomically: true)) {
    print("Could not save resource \(resource) to filepath \(fileUrl)")
  }
}

Below, you can see how we generate a random directory. In the example code, it will be a subdirectory of the temporary directory, which gets cleaned up by the OS at unspecified intervals.

func generateFolderForLivePhotoResources() -> NSURL? {
  let photoDir = NSURL(
    // NB: Files in NSTemporaryDirectory() are automatically cleaned up by the OS
    fileURLWithPath: NSTemporaryDirectory(),
    isDirectory: true
  ).URLByAppendingPathComponent(NSUUID().UUIDString)
  
  let fileManager = NSFileManager()
  // we need to specify type as ()? as otherwise the compiler generates a warning
  let success : ()? = try? fileManager.createDirectoryAtURL(
    photoDir,
    withIntermediateDirectories: true,
    attributes: nil
  )
  
  return success != nil ? photoDir : nil
}

After you have saved all the resources to disk, you can transfer them to your servers or any other destination.

Displaying Live Photos

To go in the other direction, all we need is a list of file NSURLs representing a single Live Photo. Those would have been downloaded by your app from your servers. Note that the block callback will be executed multiple times, initially providing a PHLivePhoto of degraded quality.

Note that there's currently a crasher bug in PHLivePhotoView. It manifests itself if you try to request a Live Photo from non-existing files. The workaround is to check for a non-nil photo with zero size.

func showLivePhoto(photoFiles: [NSURL]) {
  let requestID = PHLivePhoto.requestLivePhotoWithResourceFileURLs(
    photoFiles,
    placeholderImage: nil,
    targetSize: CGSizeZero,
    contentMode: .AspectFit
  ) { (livePhoto: PHLivePhoto?, info: [NSObject : AnyObject]) -> Void in
      let error = info[PHLivePhotoInfoErrorKey] as? NSError
      let degraded = info[PHLivePhotoInfoIsDegradedKey] as? NSNumber
      let cancelled = info[PHLivePhotoInfoCancelledKey] as? NSNumber
      let finished = (
        (error != nil) ||
        (cancelled != nil && cancelled!.boolValue == true) ||
        (degraded != nil && degraded!.boolValue == false)
      )
      
      if finished {
        // If you have saved `requestID`, you can now set it to PHLivePhotoRequestIDInvalid
        print("Live photo request finished")
      }
      
      if let photo = livePhoto where photo.size == CGSizeZero {
        // Workaround for crasher rdar://24021574 (https://openradar.appspot.com/24021574)
        return;
      }
      
      self.photoView.livePhoto = livePhoto
  }
}

← Back to Writings

References

PHLivePhoto Class Reference →
PHLivePhotoView Class →
UIImagePickerController Class Reference →
PHAssetResourceManager Class Reference →
NSURL Class Reference →
NSOutputStream Class Reference →
NSFileHandle Class Reference →
PHLivePhotoView crasher (rdar://24021574) →

Swift Generic Protocols

Fri, 04 Sep 2015 00:00:00 +0100

Protocols in Swift can be generic via abstract type members rather than parameterisation. Consequently, the protocol itself can no longer be used as a type but only as a generic constraint.

The Problem

If you tried to use a generic protocol as a type as follows:

protocol GenericProtocol {
	typealias AbstractType
	func magic() -> AbstractType
}

let list : [GenericProtocol] = []

We would see the following error message:

Protocol 'GenericProtocol' can only be used as a generic constraint because it has Self or associated type requirements.

If you're not familiar with generics, you might be wondering why generic protocols cannot be used as types. The explanation is quite simple — the name of the generic protocol, e.g. GenericProtocol, represents a set of types rather than a single type. If you were to have an arbitrary array of GenericProtocol, you would not be able to say anything about the return type of the magic() method, as it might be different for the various contained elements.

This is nicely illustrated on StackOverflow.

Type Members vs Parameterisation

In Swift, protocols can be made generic by using abstract type members (typealias keyword) while classes, structs, methods and functions become generic by type parameterisation (see below).

func genericFunc<T>(ts : [T]) -> Bool {
	return true; // not very exciting
}

Turns out that, in general, type members and parameterisation have equivalent expressivity — as long as any language in question fully supports both ways. We can imagine Swift supporting generic parameterised protocols in a future iteration which would make the following code possible:

protocol GenericProtocolWithParam<T> {
	func magic() -> T
}

let list : [GenericProtocolWithParam<String>] = []

If you're interested in the tradeoffs between type parameterisation and abstract type members, check out the discussion on the dev forums and the article on how the issue affects Scala.

Workaround

We can workaround the lack of type parameterisation in protocols by using a thunk. We do this by defining a struct which implements the protocol by forwarding all methods to an abstract type which implements said protocol, provided as part of the initialisation of the struct (a form of dependency injection). The actual forwarding is done with closures.

protocol GenericProtocol {
	typealias AbstractType
	func magic() -> AbstractType
}

struct GenericProtocolThunk<T> : GenericProtocol {
	// closure which will be used to implement `magic()` as declared in the protocol
	private let _magic : () -> T
	
	// `T` is effectively a handle for `AbstractType` in the protocol
	init<P : GenericProtocol where P.AbstractType == T>(_ dep : P) {
		// requires Swift 2, otherwise create explicit closure
		_magic = dep.magic
	}
	
	func magic() -> T {
		// any protocol methods are implemented by forwarding
		return _magic()
	}
}

Once we have a thunk, we can proceed to use it as a type by providing type values.

struct StringMagic : GenericProtocol {
	typealias AbstractType = String
	func magic() -> String {
		return "Magic!"
	}
}

// we can now create arrays of thunks if we specify the type param
let magicians : [GenericProtocolThunk<String>] = [GenericProtocolThunk(StringMagic())]
magicians.first!.magic() // returns "Magic!"

Self Requirement

In the context of a protocol declaration, Self refers to the type adopting the protocol. This makes the protocol generic, as Self can be thought of as syntactic sugar for a convenience type member. For example:

protocol EquatableSelf {
	func equals(other : Self) -> Bool
}

// By adopting `EquatableSelf`, every occurrence of `Self` in the protocol gets
// semantically replaced with `ImplicitStruct`
struct ImplicitStruct : EquatableSelf {
	var val : Int64
	func equals(other: ImplicitStruct) -> Bool {
		return self.val == other.val;
	}
}

If we did not have the ability to use Self, we could have achieved the same in the following way:

protocol EquatableTypealias {
	typealias EquatableType
	func equals(other : EquatableType) -> Bool
}

struct ExplicitStruct : EquatableTypealias {
	typealias EquatableType = ExplicitStruct
	var val : Int64
	func equals(other: ExplicitStruct) -> Bool {
		return self.val == other.val;
	}
}

Protocol-Oriented Programming

Protocols in Swift play a central role, as Dave Abrahams says in Session 408 (PDF) at WWDC 2015:

… When we made Swift, we made the first protocol-oriented programming language.

Watching the full video is highly recommended for any developers interested in Swift and the protocol-oriented approach. In particular, there's a very good slide illustrating the consequence of adding a Self requirement to a protocol.

Generics and Type Variance

Another issue that pops up with the introduction of generics is the variance of generic types. In simple terms, it deals with the following problem:

class Animal {
	// Animal-specific ivars + methods
}

class Cat : Animal {
	// Cat-specific ivars + methods
}

var cats : [Cat] = [Cat()]

// Here, we're typecasting from [Cat] to [Animal].
// Such typecasts could be unsafe depending on the details.
var animals : [Animal] = cats

I can suggest starting off with the Wikipedia page on type variance to further explore the issue at hand.

← Back to Writings

Scala is such a language. ↩

References