Function Overloads & Call Signatures
Some functions genuinely behave differently depending on the shape of the arguments passed in, not just their values. A single generic signature can't always express that precisely, overloads let you describe several valid call shapes for the same function.
The first two signatures are overload signatures, they describe the valid ways to call createTask from the outside. The third, with a body, is the implementation signature, it must be compatible with every overload above it, but callers never see it directly, only the overloads are checked against call sites. This is how a and b end up with two genuinely different, more precise return types instead of one overly-broad union.
Typing callable objects
A type can also describe something that's callable, not just an object with properties.
A call signature inside an interface, (message: string): void with no name, describes "this thing can be invoked like a function." Combined with an ordinary property, it types values that are both callable and carry extra data, a real pattern for loggers, event emitters, and similar utilities.
TIP
Reach for overloads sparingly, only when a single generic signature genuinely can't express how the return type depends on which arguments were passed. Most of the time, optional parameters or a union parameter type are simpler and just as safe.