# Bug: Generic type cannot check for nil **URL:** \ **Category:** Using Swift\ **Created:** [February 2, 2022, 4:45am UTC](https://forums.swift.org/t/bug-generic-type-cannot-check-for-nil/55038 "2022-02-02T04:45:10Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\ **Post date:** [February 2, 2022, 6:49am UTC](https://forums.swift.org/t/bug-generic-type-cannot-check-for-nil/55038/9 "2022-02-02T06:49:16Z")
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` aka `String?`: it is nil, or not. But consider `Optional>` 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](https://forums.swift.org/t/challenge-flattening-nested-optionals/24083). 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](https://xyproblem.info). --- _[View the full topic](https://forums.swift.org/t/bug-generic-type-cannot-check-for-nil/55038)._