We just learned how to extend any type to conform to a protocol.

Just like we can extend a class struct or a number.

But things get a little interesting when you do that.

Unlike other types where when we extend it we can add functionality.

When you extend a protocol you can provide implementations to any method or

property requirements that you have defined.

Wait, what?

When we learned about protocols we said that the purpose of a protocol

is to just define requirements and not worry about the implementation, right?

That was the job of the conforming type.

And that still holds true.

However there are certain cases where regardless of the conforming type,

the implementation remains the same.

Let's look at this simple example first.

Now in the past we've defined a protocol called Random Number Generator.

The only requirement was that conforming types

needed to provide a function that returned a random number.

So we'll add that in here.

First let's add a comment or same protocol extensions.

And then let's define this protocol.

So it was called RandomNumberGenerator

at a single method requirement a function random.

That returned a random integer.

Now let's assume that for every type that conforms to this protocol,

the implementation will always be the same.

We're going to use the arc for random function to generate a random number.

In such cases, where we will have a common implementation and

an occasional variation.

We can provide that common implementation as part of the protocol itself

via an extension.

So let's create an extension to the protocol itself and

even here inside this extension we're going to provide an implementation or

this function that we've defined as a requirement in the original protocol.

So, we'll say func random.

And we're providing an implementation which means just writing out

a normal function.

Then here, we'll say return, Int arc4random and there we go.

Now, if I were to declare a new type let's say a class called generator

and then conform to the random number generator protocol.

You'll see that I can add conformance to this type without actually doing anything.

This error should go away in a second.

And generator now conforms to random number generator, but

I don't have to provide a random function.

This is because a default implementation has been provided in the protocol and

the conforming type generator can use that.

For instance if I say let generator equal and I'll create an instance of generator.

On this I can call random and it should work.

So here the generator type is relying on that default

implementation provided by the protocol itself.

Again which we can do through an extension of the protocol.

If however we decide that we don't want this

default implementation that the protocol provides and

we want the type to provide its own specific implementation.

Well that looks just like before like we've been conforming to a protocol.

We can provide our own implementation.

So in here I'll say func random and I'll just return something

like 2 to make it obvious that it's different and you'll see now it returns 2.

Interesting, right?

Well depends on your definition of interesting I suppose.

Okay, well let's look at another example.

This one requires a bit of a deeper understanding of protocols.

Let's define a new protocol, person.

And it's going to have a first name string property that's gettable.

A last name also string gettable and

a full name, also a string, also gettable.

The requirements here are pretty simple.

Conforming types need to provide a first, last and a full name but

we know that a full name is always going to be the first name and the last name.

So let's provide a default implementation for that property.

So extension.

Remember we can only provide default implementations for

protocol through an extension.

So extension person save our full name.

I'll type string and we'll return in here an interpellated string.

Wait, what do we do here?

We can't anticipate everyone's full name, so what kind of string do we return?

Can we anticipate all the possible names?

Well, we don't need to.

Since we're in an extension of the person type,

we know all the information that's available to the person type.

Which means we know about the first name and the last name stored properties.

Now what do I mean by know about it?

The person protocol has requirements stating that conforming types

must provide a value for firstName and a lastName.

The types for these properties are non optional strings.

Meaning they cannot be nil.

Therefore we can guarantee, or the compiler can,

that conforming types will have values for the first and last name.

And since the conforming types are the ones that are going to be calling this

full name property as well, we can use the values encapsulated

by these properties in the eventual conforming type.

So right now they don't have any values but we can use them,

we'll say return firstName and lastName.

And this should work because eventually when a conforming type

conforms to the person protocol they will provide values for first and last name.

Let's see if this works by defining a new type.

This is a struct called User, that conforms to Person.

It needs a first name.

Let's get rid of that.

And a last name and let's change that to let as well.

Notice that I'm only providing the implementations in the form of stored

properties for the first and last name but we don't have any errors and that's

because again a default implementation for full name has been provided.

So if we were to create an instance,

we'll say let user = User and put my name in there.

I can now call full name on user and

you'll see that the correct string is returned.

Despite user not having an implementation.

When we call the method we use the implementation in the protocol extension

where it relies on the values provided by user for

some of the other requirements specified in the protocol.

There's a hidden aspect to this though.

Let's take a break and talk about method dispatch in the next video.