Convert implicitly unwrapped optionals to proper optionals

[AppAppWorks]

fixed #1320

[AppAppWorks]

In my original plan, I wanted to insert optional chaining for any code affected by the refactoring in the same source file, do you think it's a worthwhile and feasible effort?

[ahoppen]

In my original plan, I wanted to insert optional chaining for any code affected by the refactoring in the same source file, do you think it's a worthwhile and feasible effort?

The question is: What exactly should we do here? I can think of essentially three options:

1. If we want to make the code compile after the refactoring, we should introduce force unwraps at every location that the refactored because otherwise types might become optional that weren’t before.
2. We could introduce optional chaining in all member accesses, which possibly makes some code compile but introduces compilation errors where this produces nil where nil wasn’t acceptable before
3. We don’t do anything at the references and leave it to the user to fix things up

I would be leaning towards option (1) even though I don’t like introducing force unwraps to the user’s code base.

Is it worthwhile?

I think the biggest win with such an implementation is to have a blueprint of a refactoring that uses information from sourcekitd and the index to then perform syntactic refactorings. This refactoring in itself isn’t all that interesting, I think but it could clear the pathway for quite a few interesting refactorings. Some that come to my mind would be:

• Changing the order of function parameters
• Changing an initializer to a static method
• Changing a function to an operator