NOTE: This is pretty stream of consciousness stuff. I’m just throwing out ideas.
In the Swift language an optional is a variable that can have an unknown value. Let’s start with that. I’m not happy with the syntax of dealing with optionals, not that they exist since they have a real purpose.
First, what are the ways in which a variable can become unknown?
• Programming errors, such as forgetting to initialize an optional before trying to use it,
• Code setting it to an unknown value due to:
- Bad code/memory access
- External inputs
- A real life representation of an unknown value (such as an unknown age).
This last really represents the interesting case since it moves us from binary logic to trinary:
- I do’t know
Trinary logic lets code deal with the real world in more realistic ways and is similar to NULL values in SQL that can be queried. But, that’s beside the point.
Now lets look at some simple Swift code dealing with optionals:
This is ok and people like this but I find it feels clunky having to test for unknowns everywhere with the if let idiom when the runtime should be able to do this. There is a lot of inline “boilerplate” that interrupts the logic flow just to handle the exceptional case. Handling unknown optionals inline breaks up the intent of the code.
What if we pulled handling unknown optionals into their own scope? Let’s steal an idea from COBOL (yes!) and invent a new construct and call it wheneverUnknown. wheneverUnknown would be invoked automatically by the runtime whenever [no pun intended] it detected an unknown value in an optional. Think of this as try-catch routing except for unknowns and they are handled out of line from the main logic, which actually helps factor the code.
So what would the new code look like? Here is a mockup.
This, to me, seems more streamlined, simpler to “grok”, and is not inline. A couple of things to note here. The code after line 49 is only executed if the runtime encounters an unknown valued optional, so for all intents and purposes the logic ends at line 45.
The next thing to note is that we never handled the exception at line 45. This would be an example of forgetting to initialize an optional (bug) as opposed to the other two cases where we may not know the names. How do we handle this bug? Let’s expand our wheneverUnknown scope capabilities. The wheneverUnknown examples in this function are scoped to the function. Let’s do the same thing at the class level.
Lines 33-36 is a similar wheneverUnknown that adds an any keyword which would trap any unhandled unknown and is class-scoped. Actually, this could be moved into the function itself and would work similarly, but would be scoped to the function alone.
No, I have no plans to implement this. The idea came up looking at a Twitter post and I got into a short interchange about this idea and really couldn’t get the idea across in tweets. I just wanted to expand on the idea and clarify my thoughts a bit.