It’s more than a month from final branching of swift 5, we should expect it soon as it was announced to be released early this year. Some say that it will come later in April because the same methodology was used for Swift 4.2; the final branching for it was April 20, 2018, and it was released September 17, 2018.
Anyhow, we are eagerly waiting for swift 5.0 as it will allow us to develop apps in a beautiful manner.
One of the top priorities for Swift right now is compatibility across future Swift versions. One major component of this is ABI stability, which enables binary compatibility between applications and libraries compiled with different versions of Swift.
If Swift becomes ABI Stable, Swift will live within the iOS Operating System and it’s ABI will be compatible with every version of Swift. i.e
App1 is using Swift 5.0, but
App2 is using Swift 5.3, and their both consuming Swift ABI embedded in the Operating System.
We will enjoy this because
- Bundle size will be reduced
- Language changes will be smaller and less frequent
- Less migration effort will be required
- Developers can create pre-compiled frameworks in swift (currently frameworks are compiled when compiling your app)
This is the feature many have been waiting for! The
Result type forces the programmer to explicitly handle the failure and success cases before they can gain access to the actual value.
Swift currently lacks the ability to express this impossibility. Using
Result for the same scenario allows for much more elegant code:
Now we can write more clean and readable code which enables constraining the exact error type that may be returned.
New BinaryInteger — isMultiple
Currently, the most common way to test if a value is a multiple is by using the remainder operator (
%) checking for a remainder of zero:
12 % 2 == 0 // returns true. 12 is a multiple of 2
Similarly, testing that a value is not a multiple of another is done by checking for a remainder other than zero:
13 % 2 != 0 // returns true. 13 is not a multiple of 2
There existed many problems with this code, for example
So now we have some new things in swift 5.0 which will give relief to many.
Support ‘less than’ operator in compilation conditions
The main motivation for introducing a new “<” operator in compilation conditions is to be able to write Swift code that is easier to read.
For example, if we want to only compile some piece of code if the Swift version is less than 4.2, right now we have to write the following code:
With the introduction of support for the “<” unary operator, the refactored code would be more clear and readable:
Counting the number of objects that pass a test has a wide range of uses in many domains. However, Swift currently doesn’t give its users a simple way to perform this operation. While the behavior can currently be approximated with a
filter and a
count, this approach creates an intermediate array which it immediately discards. This is a bit wasteful.
To correctly avoid a potentially expensive intermediate array, you can use the Swift’s
lazy comes with the downside of being forced to use an
@escaping block. Lastly, you could rely on an eminently unreadable
These three solutions lie on a spectrum between “easy to write, but include performance traps” to “performant, but require Swift arcana to write”.
Swift 5.0 would avoid a performance trap and provide a simple interface for users to both read and write. Autocomplete should present it to them handily as well.
We sometimes need to transform and filter values of a
Dictionary at the same time, and
Dictionary does not currently provide an operation that directly supports compact map values.
Swift 5.0 now introduces compact map which is great, see following:
Life is getting easier, right?
try? statement currently makes it easy to introduce a nested optional. Nested optionals are difficult for users to reason about, and Swift tries to avoid producing them in other common cases.
In Swift 5,
try? someExpr() will mirror the behavior of
someExpr()produces a non-optional value, it will be wrapped in an Optional.
Optional, then no additional optional-ness is added.
This results in the following changes to the type of a
We Miss Async/Await Pattern — No more in swift 5.0
It is a well known solution used in other popular programming languages —
It eliminates the callback hell and the asynchronous APIs are difficult to work. Error Handling, Callbacks, when performing multiple operations creates complicated control flows.
How is swift without them:
Lets see what it would have been like with async-await pattern:
Anyhow, we don’t have async-await in the upcoming release but there are lot many improvements which we can benefit from.
There are many other improvements which are not mentioned in the article such as string — language level support, standard library improvements etc.
Please comment the improvements you are aware of and please let me know how do you feel about swift 5.0 and what is your favorite feature in this update :)