Limiting @objc inference”Š—”Š(SE-0160)

In Swift 3, the rule of thumb with the @objc annotation was the following.

To be accessible and usable in Objective-C, a Swift class must be a descendant of an Objective-C class or it must be marked @objc .

This means that you would have to comply your Swift class to NSObject and every property of that class would than be annotated with @objc for you by the Swift 3 compiler. The same applies when using #selector in Swift because they work with Objective-C under water.

With this proposal you now have to manually annotate every Swift class property that is used in Objective-C with @objc so the compiler can work more efficient. An simple example for adding this annotation where foo() is accessible in Objective-C is the following.

class Super { @objc func foo() { } }

Note: A migration plan is provided in this proposal. This plan gives a 3 step workflow that can help in some projects.

Improve Interaction Between private Declarations and Extensions”Š—”Š(SE-0169)

SE-0169 changes the access control rules once again. This time the access control rules are changed for private and fileprivate in combination with using a extension.

In Swift 4, we can now provide the private access level to make it accessible to a extension of the same type. Let’s explain this using examples.

In Swift 3 you could have the following program.

struct Netherlands { private var languages = ["Dutch"] } extension Netherlands { mutating func add(language: String) { languages.append(language) } // error: 'languages' is inaccessible due to 'private' protection level

The error tells that the private access level withholds the extension from accessing languages . This is strange because you create a extension for the same type so you should be possible to access languages .

In Swift 4 this is fixed and languages is accessible via an extension using private . 🎉

The breaking change in this proposal is created when there are private properties with the same signature in same type/extension but in different scopes. A Invalid redeclaration of 'signatureX' error would then follow. Changing the signature would resolve this issue.

Current codebase

Would it be possible if I could already check my current codebase against Swift 4 changes? Yes, you could!

You only need to download and install the latest Swift 4.0 snapshot and select the installed snapshot in the toolchain menu in Xcode. The following image shows where the toolchain menu is located.

When the toolchain is changed, you can now start your project and try to build it with the snapshot!

A snapshot is of course not the final version, but there are already a lot of proposals implemented of which you can create a rough estimate of the amount of work that comes ahead of you. Doing so, you know what the impact of this new Swift version will be on your existing code base.

Thanks for reading!