Challenge C

Consider the test snippet used to determine if a type has value semantics. What would you need to do in order to define an automatic means to test if a type supports value semantics? If someone hands you a type, can you know for sure if it offers value semantics? What if you cannot see its implementation? Could the compiler be expected to know?

When Apple announced Swift 2 at the World Wide Developers Conference in 2015, they declared Swift to be a “protocol-oriented programming language”. This declaration was made possible by the introduction of protocol extensions.

Although protocols have been in Swift since the very beginning, this announcement, and the standard protocol-heavy library changes Apple made, affects the way you can think about your types. Extending protocols is the key to an entirely new style of programming!

In brief, protocol-oriented programming emphasizes coding to protocols, instead of to specific classes, structs or enums. It does this by breaking the old rules of protocols and allowing you to write implementations for protocols on the protocols themselves.

This chapter introduces you to the power of protocol extensions and protocol- oriented programming. Along the way, you’ll learn how to use default implementations, type constraints, mixins and traits to vastly simplify your code.