Issue Description:

While investigating whether it was possible to convince Swift that a branch is unreachable, I discovered that assertionFailure is extremely surprising, and seems to have no sensible use-cases.

Consider the following simple function:

func test(int: Int?) -> Int {
    guard let int = int else {
        assertionFailure("Bang")
    }

    return int
}

When attempting to compile this function in debug mode, the following compiler error is emitted:

test.swift:4:5: error: 'guard' body must not fall through, consider using a 'return' or 'throw' to exit the scope

This is naturally fairly perplexing, but if the code is changed to add a return value, we could end up with the following program:

func test(int: Int?) -> Int {
    guard let int = int else {
        assertionFailure("Bang")
        return -1
    }

    return int
}

print(test(int: 5))
print(test(int: nil))

When compiled in debug mode and run, this produces the following output, as expected:

5
Fatal error: Bang: file test.swift, line 3
[1]    81717 illegal hardware instruction  ./test

When compiled with optimisations and run, this produces the following output:

5
-1

This strange strange behaviour boils down to the fact that `assertionFailure` is compiled away entirely in release mode. This means that it cannot be defined as returning `Never`, which is why surprise number 1 happens (namely, that you are forced to exit the `guard` scope in debug mode). And because it's compiled away in release mode, you run straight through it in release mode.

This function basically seems to be a worse-in-every-way version of `preconditionFailure`. It seems to serve no purpose. The distinction between assert and precondition is reasonable, as it allows coders to elide expensive checks that do not need to be run in release mode, but that does not apply here: assertionFailure and preconditionFailure are not expensive.

This confusion is widespread. For example, here is a blog post (Swift assertions: the missing manual) that mistakenly claims:

"Main difference is that assertionFailure() gives a hint to the optimizer that at this point, given context ("if" branch, or function context) ends, making it the @NoReturn effectively. In debug mode application will terminate, but in release behaviour is undefined."

This is not an accurate description of the behaviour of the function. I'd argue that it actually describes a more useful version of the function, where assertionFailure could be used to inform the compiler that a given branch should be unreachable. This was the effect I was trying to achieve when I bumped into this behaviour.