Successfully Rationalizing One's Way Out of a Suicide Squeeze & Force Unwrapping Optionals

My Babe Ruth League baseball coach was not afraid to call risky plays. He even made me pitch once which even I knew was a terrible idea, but, somehow, we escaped the inning unscathed.

There was one time, though, when I got the call for a suicide squeeze. He hoped it would go like this:

I figured it would end up like this:

Understand, I was not the Ruthian figure that I am now (...). I had a streaky bat which typically didn't get hot till the last three games of the season and this was not one of the last three games of the season. What I lacked in braun, I made up for in brains.

But you say, who needs braun to lay down a suicide squeeze? And you're right. But my team sucked, I sucked, and runs were few and far between. If I missed the bunt, if I fouled it off, or if I bunted it in the wrong direction, we're toast and the opportunity is lost.

So I did some quick math: First, this was junior high baseball: There was no shortage of errors, wild pitches, and passed balls to be had. While the pitcher threw hard, today he had proven to be wild. And while catchers in this league were typically one of the three best players on their team (behind the pitcher and the shortstop), the kid behind the plate today was not a brick wall or vacuum cleaner. Plus, as a right-handed batter, granted a 5'4" 100 lbs one, the catcher still had to catch the ball, get around the hitter, and make the tag to successfully stop a suicide squeeze.

While I got the sign to lay down the suicide squeeze from my coach at third, I told myself, "Self, if you get a good pitch, bunt it. If you get a bad pitch, let it go: The runner from third will still score."

What happened?

I got a bad pitch.

What happened to the runner?

The runner scored.

Barely.

Then what happened?

My coach chewed me out for not laying down the bunt like I was told to. Fair enough.

So far we've talked about how we can use optionals to protect our code from crashing when the data or values we hope are there are not there. But sometimes you are so confident about something you just want to go through with it consequences be damned.

I told myself not to bunt because I had faith that the pitcher, the catcher, or both would blow it, I didn't bunt, and we scored. It worked.

Going forward with such faith in Swift programming is called force unwrapping an optional. Again, doesn't quite roll off the tongue, but stick with me. Let's take a look and then walk through it.



What's going on here? Let's pretend a PA announcer has to announce the next hitter, but it's a crucial point in the game. One team might switch pitchers. The other team might bring up a different hitter. There's uncertainty everywhere. So the PA announcer makes the name he's going to announce next an optional (See the ? after String on line 6?) just in case he doesn't get the name in time.

Turns out, Sanchez is going to hit. We know that because we've assigned "Sanchez" to the string variable playerSurname. Now that we know who's going to hit, the announcer can make his announcement, "Now batting, Optional("Sanchez")\n". If we read between the lines, we can assume that the player's first name is not Optional and that that is just some computer language in there.

In fact, that is how I explain why we call them wrapped or unwrapped optionals. In the above example, the string optional "Sanchez" is still wrapped in the "Optional("string")\n business. And wrapping, as we like to think, adds an extra layer around something.

 But what if, in this moment of uncertainty about who's up next, the PA announcer goes out on a limb and just announces Sanchez as the next hitter. Well, that's what forced unwrapping an optional is like. Here's what that looks like:



By adding an exclamation point (!) to playerSurname on line 8 we force unwrap that optional and we know we've force unwrapped it successfully because one, we see, "Now batting, Sanchez\n" on the right hand side of line 9, and two, because that Optional("Sanchez")\n business is now gone. Why is the optional wrapping gone? Because we've forced unwrapped it.

Now, what happens if the PA announcer doesn't know the name of the next hitter, but mumbles out something just the same? Here's how that goes:



In short, it doesn't go well. The announcer thought he could get away with mumbling, but instead he gets a Bronx cheer, a big error message appears in red on the Jumbotron in centerfield, and the fans crash his booth (or, at least, his program).

Why is force unwrapping optionals important?
Sometimes you just want a program to run because you are that confident that data will be there. If that's the case, force unwrapping optionals is important and useful.

When does one use force unwrapping?
One only force unwraps optionals when absolutely certain that the data is there. This is like swinging at a 3-0 pitch. In most cases, you don't do it. But when you're down by three with two outs in the bottom of the ninth at home, the pitcher is gassed, and you've got your best hitter up, give 'em the green light because that's about as ideal as it's going to get.

Challenge: Re-write the example above with the name of your favorite relief pitcher and then tweet it to me (@randallmardus).

On Deck: Classses