What’s new in latest version Swift 5.3 ?

What’s new in latest version Swift 5.3 ?

As we are working with swift and seeing that Swift language is evaluating very rapidly. Apple has announced on 25 March a new release version process for Swift 5.3 has scheduled.
So, in this tutorial we will be discussing about new features that will be coming with new release of swift 5.3, these features are going to change our development experience.
This release of Swift 5.3 meant to import prominent performance and quality improvements, lots of new features already implemented on branch for 5.3 release version.
If you are much eager to those features then you can give them a try by installing latest snapshots provided by Apple using swiftenv, snapshots can be found on swift.org.
Let’s start with it.

Let’s start with it.

1. Optional Value Setter ??=

Problem/Motivation:

In many cases the ?? operation doesn't help with lengthly variable names i.e. object.property.lvalue = object.property.lvalue ?? "".
In addition to other operators i.e. object.property.lvalue += 5which works the same way and which is very popular.

Proposed Solution:

SE-0024 introduce a new operator ??=, allow us to assign default value for optional values right away if they have .None

As of this solution, optional values would be set iff property contains .None, for .Some value will not change, ideally willSet and didSet are only called if this operation occurs.

2. Refine didSet Semantics

Problem/Motivation:

As of now till swift version 5.2, if we have a didSet observer for any property, Swift always calls getter for that property to get the oldValue, even if the observer does not refer to the oldValue in its body. For example:

Old didSet example

It might be harmful when we are performing thousand number of operations, it will create thousand copies of property to provide the oldValue.

Proposed Solution:

SE-0268 provides solution for this problem, getter of the property should not be called if didSet of property doesn’t refer oldValue.

Same will be applied for didSet of overridden properties as well, getter of super class will be skipped if didSet doesn’t refer oldValue.

3. Multi-Pattern Catch Clauses

Problem/Motivation:

As of now till swift version 5.2, we are allowed only up to one patter or where clause with each catch clause in a do-catch statement.
Due to this if we need to handle many error cases with single catch clause we are not allowed to do so. i.e.

error in old do-catch statement

Because the above snippet is not valid today, developers frequently end up duplicating code between catch clauses, or writing something like handling errors in a single catch clause with switch statement.

Proposed Solution:

According to SE-0276, developers should be allow to write comma-separated list of patterns with a single catch clause. A specific catch clause body will be execute when a thrown error matches any of the patterns in a corresponding catch clause at runtime in do block.

Now, if igniteRockets throws either RocketError.noAstronauts(let message), RocketError.outOfFuel(let message) or RocketError.unknownError(let message), the body of the last catch clause will be executed, either error can be print or message can be shown.

4. Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur

Problem/Motivation:

Currently in swift version 5.2, while using escaping closures we forced by Swift compiler to all use of self in order to prevent from creating unwanted retain cycles.

class self in escaping closure

Same goes with struct as well, i.e.

struct self in escaping closure

In order to make our code compile we need to add self before isCoding in closure’s capture list or body i.e. self.isCoding = true.

Proposed Solution:

According to SE-0269, we will be allow to use implicit self in place of explicit self, when self appears in closure’s capture list or body.
For class: Now, this example can be written as:

The compiler would also offer an additional fix-it (commented line in above code) when implicit self is used in closure’s capture list or body.

For struct: as self is a value type, we will not require any explicit usage of self (at the call/use site or in the capture list), so that if self were a struct or enum then the above will run without any error.

5. Synthesised Comparable conformance for enum types

Problem/Motivation:

Frequently, we need to define an enum where all the cases have an obvious semantic ordering. And we might need to perform some operations i.e. comparison and sorting etc.
However, implementing these kind of requirements it requires a lot of boilerplate code which is error-prone to write and difficult to maintain.
Let’s have an example:

comparable enum in swift

So, in this example, as of today, we need to implement Comparable protocol, provide comparisonValue and override less than operator. After doing so many things we can use sorted() method on array of enum type.

Proposed Solution:

As proposed in SE-0266, synthesised Comparable conformances for eligible types will work exactly the same as synthesised Equatable, Hashable, and Codable conformances today. A conformance will not be synthesised if a type is ineligible (has raw values or non recursively-conforming associated values) or already provides an explicit < implementation. Like:

So, we will not be necessary and we don’t need any additional code to compare enums.

6. Tuples Conform to Equatable, Comparable, and Hashable

Problem/Motivation:

Tuples in Swift currently lack the ability to conform to protocols. This has led many users to stop using tuples altogether in favour of structures that they can them conform protocols to. The shift from tuples to structures have made tuples almost feel like a second class type in the language because of them not being able to do simple operations that should work.

After all these kind of errors, as a solution we decide to give in and create a structure to mimic the tuple layout.

Proposed Solution:

With SE-0283, above code will be compile without any error because it introduce Equatable, Comparable, and Hashable conformance for all tuples whose elements themselves conform to said protocols. While this isn't a general purpose conform any tuple to any protocol proposal, Equatable, Comparable, and Hashable are crucial protocols to conform to because it allows for all of the snippets above in Motivation to compile and run as expected along with many other standard library operations to work nicely with tuples.

7. Type-Based Program Entry Points by @main:

Problem/Motivation:

As of now, our swift programs start executing files at the beginning. It works great for procedural code, and allows simple Swift programs to be as short as a single line, with no special syntax required.
Ever since its initial release, Swift has provided the domain-specific attributes @UIApplicationMain and @NSApplicationMain to smooth over this startup process for developers of UIKit and AppKit applications.

And in main.swift file the following line already written to provide the entry point by creating a terminal app for our application:

UIApplicationMain(
    CommandLine.argc,
    CommandLine.unsafeArgv, 
    NSStringFromClass(MyApplication.self),
    NSStringFromClass(AppDelegate.self)
)

When we need to change the entry point of the application we need to make changed in main.swift file, many of us are not aware about this.

Proposed Solution:

With help of SE-0281, The Swift compiler will recognise a type annotated with the @main attribute as providing the entry point for a program.
So that the author of a Swift program, we just need to use the @main attribute to indicate the correct starting point. Like:

When this runs, Swift will automatically call NewAppDelegate.main() to start your code.
The new @main attribute will be familiar to UIKit and AppKit developers, where we use @UIApplicationMain and @NSApplicationMain to mark our app delegates.

8. Add Collection Operations on Noncontiguous Elements

Problem/Motivation:

There are varied uses for tracking multiple elements in a collection, such as maintaining the selection in a list of items, or refining a filter or search result set after getting more input from a user. We can use a Range<Index> to refer to a group of consecutive positions in a collection, but the standard library doesn't currently provide a way to refer to discontiguous positions in an arbitrary collection.

Proposed Solution:

As per SE-0270, adds a RangeSet type for representing multiple, noncontiguous ranges, as well as a variety of collection operations for creating and working with range sets. Like:

RangeSet is generic over any Comparable type, and supports fast containment checks for ranges and individual values, as well as adding and removing ranges of that type

9. Added Float16 in library:

Problem/Motivation:

The last decade has seen a dramatic increase in the use of floating-point types smaller than (32-bit) Float. The most widely implemented is Float16, which is used extensively on mobile GPUs for computation, as a pixel format for HDR images, and as a compressed format for weights in ML applications.

Proposed Solution:

According to SE-0277, added Float16 to the standard library.

For performing math operations Generic Math(s) Functions are also proposed.

There are some more accepted in review proposal to explore and learn on Swift Evolution Dashboard. New version of Swift as 5.3 going to released with some remarkable new features those are most awaited by all the swift lovers.
I’m very happy that swift is evolving more frequently 😊.

👩‍💻 !!! KEEP LEARNING !!! 👨‍💻

Thank you for reading, please hit the recommend icon if like this collection 😊. Questions or Doubts? Leave them in the comment, let’s discuss more on them.