Swift 5.7: Unwrapping Optionals Gets an Improvement | by Avi Tsadok | Apr, 2022

Unwrapping optionally available variables in Swift is among the commonest growth duties iOS builders carry out hourly.

It’s so frequent that unwrapping is among the hottest questions requested in interviews.

And within the context of unwrapping, I’m going to point out a small “syntactic sugar” that involves Swift 5.7.

This is among the instances the place the change per se will not be that necessary — however the dialogue round it’s rather more.

And to grasp why we first want to speak about one thing referred to as Shadowing.

We’ve all been there.

We’ve an optionally available, and we wish to unwrap it.

Once we unwrapped the optionally available x, we created a brand new fixed additionally named x, which incorporates the identical worth, and now we use this fixed as an alternative of the optionally available variable.

This motion is named Shadowing — as a result of the brand new fixed is sort of a shadow of the unique optionally available we needed to unwrap.

Is Shadowing good?

Properly, there are obvious the reason why shadowing an optionally available variable could cause us some points.

First, the instance above doesn’t characterize actuality.

Variable names are longer, generally for much longer.

For instance:

Okay, possibly too lengthy :), however you get the purpose. Lengthy-named optionally available variables create prolonged unwrapping code with no justification. It simply seems…properly..bizarre.

So, what will we do? Oh, I do know, let’s shorten the title!

Okay, so we shortened the title to “date”, and now, it’s unclear what “date” means. We all know that naming performs a major key in writing readable code, and we gave a deep considered naming our optionally available variable.

So, if we return to Shadowing (I imply, preserve the unique title), we stumble upon a brand new concern — we now have two variables with the identical title. After all, we all know easy methods to deal with that (we’re all professionals), however it’s nonetheless not one of the best follow, isn’t it?

We see that Shadowing (which all of us use!) will not be that harmless.

Because of this, Swift 5.7 has an attention-grabbing new strategy to dealing with the scenario.

However, this strategy might increase new points. Let’s discuss it.

The answer may be very easy.

As an alternative of:

We will do the next:

And when the variable is lengthy, this answer actually turns out to be useful:

Now, in fact, this answer can also be related for one more shadowing unwrapping:

However, is it excellent?

Some say that shortening the way in which Swift 5.7 permits additionally has its drawbacks.

For instance, when performing:

We type of preserve shedding the context of x. It looks like x is a brand new variable that has no worth. The “= x” gave us context and mirrored that we used an present variable.

The second purpose could also be much more profound.

We mentioned that Shadowing won’t be a very good strategy. One of many causes is to create duplicate variables.

However the answer doesn’t forestall us from Shadowing — even worse! It encourages us to shadow optionally available variables and, by that, dig the outlet even deeper.

As an “outdated” developer, will probably be exhausting for me to shorten my unwrapping, so I won’t be the right instance.

However I feel this new Swift 5.7 function can educate us fairly a bit about naming, duplicate variables, and readable code.

What do you suppose? Do you prefer it?

More Posts