Even as a language user, "checking for nil" is somewhat ambiguous because optionals can be nested.
The simple case is plain optionals, such as Optional<String> aka String?: it is nil, or not.
But consider Optional<Optional<String>> aka String??: it can contain a string .some(.some("foo")), or two kinds of nil: .none and .some(.none).
Add more levels of optionality, and you have even more "kinds of nil".
The game here is to understand what the OP is after, which "kind of nil" has to be checked for.
Is it only dealing with plain single-level optionals? In this case, there is no need for a isNil function: value == nil is just enough, and there's not much any question.
Since there is a question, I guess we're talking about "flattening nested optionals", or "deep unwrapping of optionals". There are multiple threads about this topic in this forum, and one I can remember is Challenge: Flattening nested optionals.
And if this guess is wrong, then I advise @vitamin to tell what is, exactly, the initial problem to solve. Focusing on the isNil function, much likely a by-product on the way to solve the initial problem, is probably a loss of time for everybody.