In the last video,

we replaced the array if strings with an enum that was more clear and concise.

But our function still returns a string,

which is then used again in another function.

We're repeating the same kind of mistake here that we tried to eliminate in

the last video.

So let's try and fix that, from our dayType function here,

we're returning a string.

Let's take a look at that more closely, when it's Saturday or

Sunday, we return a Weekend.

Or if it's any other case we return Weekday,

I hope you've noticed the pattern here.

There are only two possible values that can ever be returned,

either a day is a weekday or it's a weekend.

This data set is another great candidate for an enum, so let's create another one.

We'll add it right after day, and this time we'll call the enum.

So we'll start with the enum keyword and then for the name will state dayType and

we'll give it two members.

So again we start with a case keyword to define a member, and

we use a lower camel case so we'll say weekday and then weekend.

Now if we go back to our dayType function for Saturday and

Sunday we can return, instead of a string dayType.

Oops, DayType.weekend, and for

the rest of the cases we can return DayType.weekday.

Because we're not returning strings anymore,

let's change that return type to DayType.

Now, we don't have a single string literal in this function, and

there's barely any room for mistakes.

So, now let's tackle that second function, and this one's even easier.

Given the day of the week we either return true, if notifications should be muted,

or false if not.

So we'll write out the same function again isNotificationMuted

external name of on, local name of type.

And now we'll specify DayType as the argument type, and return a Bool.

Earlier when we were talking about switch statements,

I said that we were only touching the tip of the proverbial iceberg.

And that it was capable of so much more.

Now we're going to start seeing that,

switch statements are really made to go with the enums.

Because the switch statement can infer the range of values, we don't have to worry

about default clauses, and not accounting for a particular path in our code.

In the body of this function, let's add another switch statement and

switch on the type of day.

So in the case of DayType.weekend,

we do want our notifications to be muted, so we'll return true,

and in the case of DayType.weekday we'll return false.

Let's take a look at what we've done here,

we took a dataset up at the top there was an array of strings.

And two functions that accepted strings to build some functionality.

This way was quite error prone, because one mistake in

writing out those strings and everything comes to a crashing halt.

We've replaced this with two custom enums, and now everything is much more elegant.

We can't make mistakes because X goes on to complete and

the compiler help automatically weed those things out.

This is pretty important,

a lot of app crashing errors are caused by using strings to specify values.

There are a couple things we can make a bit nicer in our code

syntactical sugar if you will.

If you're unfamiliar with that term it just means a language feature

that makes it easier to read or

express certain code, and enums certainly come with their own sugar.

First of all, because we've specified that the parameter day inside

the first function will be of type Day, we don't have to write out Day.Saturday,

Day.Sunday and so on.

We can simply emit the Day and do period .Saturday and then .Sunday.

And the compiler can figure it out, because the compiler knows that this case

is a potential option when switching on day which is of the type Day.

It figures out that these are valid values,

it figures out that .Saturday really means Day.Saturday.

But that's less for us to type,

in fact we can get rid of it everywhere inside this function.

So instead of saying DayType.weekend, we know that the return type is DayType,

so we can omit it here and infers that weekend is a valid value.

Let's do it everywhere else, Day.Monday becomes .Monday,

.Tuesday, .Wednesday, .Friday and .weekday.

Cool?

We can do you even better, we can omit the type declaration

in the second function for the same reason as well.

When we first learned about type inference and implicit versus explicit types,

I mentioned I would bring it up again when it was relevant.

Well it's quite relevant here,

we wrote code that's actually quite nice and readable.

We switch on a day and if the day Saturday or

Sunday we return weekend that is very readable.

Now the actual type though is omitting these case statements, and

that's a matter of judgement and style as to whether you want to write it there.

Now in here, let's get rid of DayType.weekend and DayType.weekday.

It's worth noting that we don't have to list out all the enum cases over here,

monday, tuesday, wednesday, thursday, friday, for the weekday option.

Since only two values returned a weekend and then every other value in the day enum

returns weekday, we can simply get rid of all this and make it the default case.

We also don't need to write out the word case every time, so

up in our enum declarations we can change it to say case weekday, weekend and

this is the exact same as writing every single one out on an individual line.

I like to keep things separate though so

I do like them on separate lines with individual case statements.

There's one thing I should mention before I end this video

you'll notice that I've written four functions in total.

There's two of them up at the top, dayType and isNotificationMuted, and

then two below that also say dayType and isNotificationMuted.

Now you may have noticed in previous lessons,

that sometimes we type things with the same name and we got an error.

So how are we doing it over here?

How do we have two functions named dayType and

two functions named isNotificationMuted?

This is a feature of Swift called function or

method overloading, where you can have two functions that have the same name

as long as they take different parameter types.

So for example DayType here, takes a string as an argument and

dayType here takes Day as an argument.

So in reality, they are two different functions,

even though they have the same name.

Now when you call the function, let's go ahead and do that.

And say let dayType =, and when you start typing the function name,

you'll notice that we have two different options with the different types listed.

So over here we want the one that takes a Day.

Now because this compiler over here, knows this parameter is of type Day,

the second I add a dot here it'll auto complete and show me all my options.

And a nice feature here is that we can see all the range of values in the enum, so

I can select Saturday.

Now I'm going to name this just type, so it's a bit more readable.

And then you'll see here that when we do this in the results pane weekend is shown

which is nice and readable again.

Let's finish up this example by calling our last function, so

we'll say let's make sure I have a different variable name.

So I have isMuted up here, I'm going to comment these out.

And then down here I'll say let isMuted = isNotificationMuted,

and again we have both options.

And we wanna take the one that takes a DayType and we can pass in the type and

you'll see the value is true.