Optionals: Training Wheels?

Optionals in Swift are simply the compiler forcing you to identify what variables you create that you want to be nil at times.

Before Optionals, a variable was nil unless it was initialized.

If you accessed the variable when the value was nil your program would produce a runtime crash. So you needed to check for nil-value before you accessed the variable, and then only when you knew it could be nil, otherwise you accessed it without the check.

This has worked fine for decades and still works fine in many other languages.

So why Optionals? After all, you always had the ability to assign nil to a variable. You programmed on the premise that any variable could be nil, but you know the ones that aren’t nil because you initialized them.

By forcing a variable to be Optional when you need it to be nil at times creates unnecessary and convoluted code! Optional Binding is a great example of this (creating a variable of your variable). Not to mention the constant use of ? and ! or the unnecessary strategies to avoid using them. These all force you to change your code flow to accommodate the Optional rules. And this can get quite thick at times. Ask yourself if this isn’t true when you find yourself changing your code -to avoid the compiler error-, when you -know- your usual and simpler code would not cause a runtime crash if there weren’t Optionals.

Although Swift provides ways around this by allowing the declaration of a variable as being unwrapped as nil ( var selectedColumnIndex: Int! ), we are forced to use Optionals (and get good at them) if we want to interact in a production setting where the existing code uses Optionals.

Optionals are like a department store forcing you to have your open bag tapped-up when you enter their store. This forces the conscientious programmer to be forever subjected to this to accommodate the careless programmer.

Think of all the simple, elegant, and readable code strategies that will have to be changed to accommodate Optionals.

The question is: Does all this really translate into applications that are -truly- “safer” than the countless applications that have been running crash-free for decades, and do it well -without- optionals?

Truly, Optionals are like forcing training wheels on anybody who knows how to ride a bike, do we -really- need them?

nil wasn't the only option. Most of the types I used couldn't be nil before I came to Swift, unless I said so. In C#, nullable value types made code much cleaner. So I'm happy to have standardization between reference and value types.

Yes we need them, if you dont believe that, see list of current null pointer related Common Vulnerabilities and Exposures (CVE): ;-)


cve.mitre.org/cgi-bin/cvekey.cgi?keyword=null+pointer

I disagree... I think of optionals in the opposite way... They're an opportunity for the developer to clearly reason about and explicitly annotate which values can never be nil and which ones can be nil. IMHO, optionals make code much more readable because in any given snippet of code, you have complete awareness of the nullable state of a variable... You don't have to go scanning upwards to figure out if it was nil-checked somewhere else.

Optionals: Training Wheels?
 
 
Q