Extensions on Andrew Bancroft

3 Nuances of Swift Extensions

Wed, 22 Apr 2015 17:52:36 +0000

How often do we take an initial cursory look at some documentation, shake our heads and say, “Ok, sure! Got it!”, and then some time later get to the actual usage of that perceived understanding only to find out, “Woah – this is behaving differently than I expected! I wonder if the documentation says anything about this?!”

A few discussions I’ve had recently have prompted me to question what I thought I knew about Swift extensions. I have read documentation about extensions and I thought I understood them pretty thoroughly. However, these conversations, along with some experimentation done on my own revealed a few nuances that I didn’t pick up on before.

Update: Almost immediately after publishing this article, the Swift community chimed in and helped me figure out my fundamental hiccup which prompted the aforementioned experimentation in the first place. I’ve written a follow-up article called “Clarifying Swift Access Control”, describing that misunderstanding. I recommend giving that one a read to avoid making the same mistake I did!

Three nuances of extensions

In particular, the following three nuances challenged what I thought I knew about Swift extensions:

The visibility Swift extensions have into the Type they’re extending. Can they see things marked private, for example?
How that visibility is affected by where the extension is defined. If I have the source for a Type that I’m writing an extension for, does defining it within that same source file vs defining it in a separate file affect what it can “see”?
The default access modifiers of the extension’s “members” and how specifying them or not specifying them affect what an extension exposes as public API for the Type it’s extending.

Before I begin, suppose that I have a public struct called Person. It has some private properties, name, gender, and age. An enum encapsulates the idea of Gender. The struct looks something like this:

 1public struct Person {
 2    private var name: String
 3    private var gender: Gender
 4    private var age: Int
 5    
 6    public init(name: String, gender: Gender, age: Int) {
 7        self.name = name
 8        self.gender = gender
 9        self.age = age
10    }
11    
12    public func howOldAreYou() -> String {
13        return formattedAge()
14    }
15    
16    // private func, simply to show extension visibility traits in the analysis below...
17    private func formattedAge() -> String {
18        switch self.gender {
19        case .Male:
20            return "I'm \(self.age)."
21        case .Female:
22            return "Not telling."
23        }
24    }
25    
26    public enum Gender {
27        case Male
28        case Female
29    }
30}

Now, suppose that I wanted to extend Person and inspect the three nuances about the extension’s capabilities and behaviors that I introduced at the beginning of this article…

Extensions and visibility into extended Type

When I introduced that first nuance about visibility into the extended Type, I asked the question, “Can they see things marked private?” The answer surprised me at first: Yes…they can.

However, here’s where the second nuance comes in: It absolutely does matter where the extension is defined.

Defined within same file

Extensions defined within the same file as the Type they’re extending have access to private members of that Type.

For example, defining an extension to Person within Person.swift allows the extension to access private properties and functions! Who knew?!

1extension Person {
2    func getAge() -> Int {
3        return age // compiles, even though age is --private--
4    }
5    
6    func getFormattedAge() -> String {
7        return formattedAge() // compiles, even though formattedAge is --private--
8    }
9}

“What?? Why?”, I thought to myself…

My reasoning as to why extensions defined within the same file behave this way is because when it comes down to it, I could have just written the extension’s implementation as part of the Type itself and it would have had the same effect.

I’m in the source file of the Type I’m “extending”. So whether I write the additional functionality as an extension for the Type, or just define what would have been in the extension inside the Type, itself, the net effect is the same.

Therefore, the compiler essentially says, “I see this extension being defined, but there’s really no point. It’s in the same file that the Type is defined in… so the developer could have just written all this code within the Type itself… so I’ll let him/her refer to private code blocks.”

Update: My reasoning above reveals that I truly didn’t have an understanding of Swift access control. I recommend giving my followup article titled “Clarifying Swift Access Control” a read for more details!

Defined in a separate file

Moving the extension definition into a separate file, however, causes the extension to lose that visibility into the Type it’s extending.

Following the inverse of my previous reasoning about private visibility when the extension is defined within the same file, this behavior actually makes sense to me.

Most of the time, you’d be writing an extension for Types that you don’t have the source to. In that scenario, extensions would have the same visibility that any client of the Type’s exposed API would have, namely, the things marked public.

Default extension access control

The final nuance also yielded some semi-surprising results for me. Apple’s documentation says it, but until I experimented and saw it in action, I didn’t catch the nuance around the default access control modifiers applied to extensions.

Default access when no explicit access modifiers specified

In short, when you declare an extension but specify no explicit access modifiers (ie, you just use the default), the extension’s default access level depends on the access level of the Type it’s extending.

If the Type is public or internal, the extension’s implementation “members” will be internal by default. The “surprise” for me I think is that extensions for public Types have internal members by default, unless you specify otherwise.
If the Type is private, the extension’s implementation “members” will be private by default.

Here’s what the extension looks like if we analyze it from the perspective of using no explicitly declared access modifiers (note that to gain access to private properties and functions, I’m declaring the extension within Person.swift):

 1public struct Person {
 2    // ...
 3    
 4    // ...
 5}
 6
 7extension Person {
 8    func getAge() -> Int {
 9        return age
10    }
11    
12    func getFormattedAge() -> String {
13        return formattedAge()
14    }
15}

Using the default access modifiers as shown in the code snippet above exposes access to the extension’s new API to instances within the same module. However, it does not expose additional public API for the Type it’s extending to a client of that Type that’s in another module (for example, the unit test target, which is another Swift module).

Same Module

Different Module (test target)

For some reason, I had it in my head that if a Type that I’m extending is public, the extension’s members would default to public. I don’t know why I thought that, but thankfully my experimentation cleared up!

Default access when using default extension declaration, but specify public for implementation

Adding public access control modifiers to the extension implementation’s members makes those members visible everywhere (that is, both within the same module, and within the test target).

The location of the extension’s declaration, be it within the same source file as the Type it’s extending, or in a separate source file, does not matter in terms of what the extension exposes when adding public members… But only extensions declared within the same source file as the Type it’s extending can see private members of that Type, as we discovered previously.

Extensions declared in same and separate source files

Public extension members visible in different module (test target)

But notice that on the line where I’ve written extension Person { ... } that I haven’t specified an access control modifier for the extension, itself. I’ve only added public to its members. Even still, the new functions are visible to the test target which is a different module.

In other words, there’s no need to write public extension Person { ... }. Since Person is public, the extension just uses the Type’s access level for its own declaration.

Wrapping up

The three nuances about Swift extensions that were analyzed here were “surprising” enough to me to warrant some experimentation. My hope is that the analysis that was done will help clear up these subtleties for others who are struggling with understanding how Swift extensions behave!

Send a Type to Obedience School – Using Swift Extensions for Additional Protocol Conformance

Tue, 02 Dec 2014 19:15:33 +0000

Did you know that you can make any Type (here meaning Class, Enumeration, or Struct), even already-existing ones that you don’t have the source code for, adopt a protocol that it doesn’t normally conform to out of the box?

You can – even if you don’t have the original source code for that Type! It’s a powerful and intriguing proposition. Let’s explore how this is possible.

How, you ask?

Well, as the title of this article suggests, Swift extensions are the way to do it. To demonstrate this capability, consider the following scenario:

You’re using a library that lets you create instances of Bird , and you don’t have access to the source code for the library.
Bird has a property called species and a property called commonName .
You’d like Bird to conform to the Printable protocol, defined in the Swift standard library, so that you can call println(_:) on Bird instances, and have it log something useful to the console.
When println(_:) is passed a Bird instance, you’d like it to print out something like “[species] (ie, [commonName]).”, and have [species] and [commonName] be replaced by the Bird‘s real values.

Remember that you don’t have access to the original source code of Bird . Without Swift extensions, there would be no way for you to tell the compiler that you’d like Bird to adopt and conform to the Printable protocol.

Thankfully, extensions do exist, and we can teach a Bird new tricks, enabling its conformance to Printable .

Protocol Conformance Extension

As stated in the Printable protocol documentation, a Type adopting the Printable protocol must implement a single, read-only property named description .

The extension, then would be implemented as follows:

1// Explicitly specify protocol adoption
2extension Bird: Printable {
3
4    // Implement the required property to make Bird conform to the protocol
5    var description: String {
6        return "\(species) (ie, \(commonName))"
7    }
8}

The magic line in the code above is highlighted. This tells the compiler that Bird will be extended to adopt the Printable protocol.

Of course, the remaining requirement then, is to implement the specification of the protocol so that Bird conforms to it, which is what the body of the extension contains.

Note that simply extending Bird to have a read-only description property will *not suffice for making the Type adopt the protocol. There is no “implicit” protocol adoption in Swift, so you must specify in the extension declaration that you intend for the Type to adopt the protocol.

Conclusion

With this little example, you’ve seen how using an extension can enable a Class, Enumeration, or Struct to adopt and conform to a protocol that it normally wouldn’t out of the box. It’s especially neat that you can do this for any such Type, whether you have control over its original source code or not.