What are a few scenarios in which we can't avoid using implicitly unwr

1.	What are a few scenarios in which we can't avoid using implicitly unwrapped optionals and why so?
Answer» The FOLLOWING are the most prevalent reasons for using implicitly unwrapped optionals: When you can't INITIALISE a PROPERTY that is not nil (absence of value) by definition at the MOMENT of instantiation. An Interface Builder outlet, for example, is always initialised after its owner. In this case, you have ensured that the outlet is non-nil before using it, provided it's properly configured in Interface Builder. To tackle the problem of a strong reference cycle, which occurs when two instances refer to each other and one of them requires a non-nil reference to the other. In this situation, one side of the reference is MARKED as unowned, while the other employs an implicitly unwrapped optional.

What are a few scenarios in which we can't avoid using implicitly unwrapped optionals and why so?

Answer»

The FOLLOWING are the most prevalent reasons for using implicitly unwrapped optionals:

When you can't INITIALISE a PROPERTY that is not nil (absence of value) by definition at the MOMENT of instantiation. An Interface Builder outlet, for example, is always initialised after its owner. In this case, you have ensured that the outlet is non-nil before using it, provided it's properly configured in Interface Builder.
To tackle the problem of a strong reference cycle, which occurs when two instances refer to each other and one of them requires a non-nil reference to the other. In this situation, one side of the reference is MARKED as unowned, while the other employs an implicitly unwrapped optional.