0:00 The solution here is, obviously, we're going to need a function here instead of a const. Let's fix that. We're going to need to add overloads for each specific case. For this case, we're going to need to add an overload. For the next case, we need to add one. Let's go with that one first. Let's go with function youSayGoodbyeISayHello. Greeting when it's hello will return goodbye.

0:24 This is good, because now the first case is being handled, but there's a strange error here. Now we have youSayGoodbyeISayHello, this one, it's saying, "I was expecting hello, but you passed goodbye." That's really strange because, surely, it should be catching this one here.

0:44 This is a really confusing but important part of function overloads, which is when you have an overloaded function like this, the implementation signature is not exposed outside of the function. This then becomes an internal signature.

1:01 This is still important because if you have, let's say, this was a number instead here, then you would get an error here because this overload signature is not compatible with the implementation signature. In other words, hello has to be assignable to greeting. You can have this as string, for instance, if you want, but hello/goodbye makes a lot of sense.

1:20 We know now what we need to do because this is currently the only one being exposed to the real world. Now let's just swap these over, add another implementation signature there, or another signature there rather, and it starts working.

1:35 This is pretty cool, because before we solve this with conditional types, and it was pretty messy code-wise, this is actually pretty simple to read. It's quite declarative. You have a hello and that returns goodbye. Have goodbye and that returns hello.

1:51 Then the implementation signature is left a little bit to not worry too much about what it returns, because technically inside here, and I wonder how far we could push the limits here, if we return a number here, then this one is going to say, "This overload signature is not compatible." If we return just like a blah, blah, blah, blah, blah, then it's actually not quite type-safe, as you can see.

2:15 We can make it a little bit more type-safe, but we have to be pretty strict with ourselves. We can add this return type signature. You notice that function overloads are not a particularly type-safe form of TypeScript, or rather, it means that the implementation part of the function overload is not really held to a very high standard in terms of being super-duper type-safe.

2:41 What I would probably recommend whenever you're doing a function overload is in the implementation signature, type the return type and make sure manually that the return type matches up to this other stuff here. If we put something random in here, then this is going to yell at us. It's going to say, "This overload signature is not compatible with its implementation signature."

3:04 I really do like this code because these overloads are much easier to read. They give you a really good sense just by looking at the function, what it does. For someone who's not au fait with really advanced TypeScript, this is going to be a pretty nice way of handling things for someone just stumbling on this code. Function overloads, they're pretty good. They can pull their weight.