Love them or hate them, macros are an integral part of C development, and are widely used throughout the Objective-C Cocoa and Cocoa Touch frameworks. If you’ve ever used
NSAssert, then you’ve used a macro. (And if you haven’t, then what have you been doing?!)
Now please bear with me… before all you macro-haters completely disregard this blog post, this is not another one of those posts that explains the trivial procedure of re-writing a function-like macro as a function in Swift. Nor will I show the Swift alternative to a macro definition of a primitive constant, as I’ve seen in other recent posts within the community.
In this short series, I’m going to look at some of the more creative uses of C macros and investigate how we could use some of Swift’s advanced language features to accomplish the same results.
Misuse of macros
I have come across a few blog posts recently which take various types of Objective-C macro and find alternative solutions in Swift. But every macro discussed could have been written as a function (or even worse declared as a constant) in Objective-C in the first place, so would be trivial to convert to Swift. I was going crazy staring at the screen in disbelief of people converting macros such as the following:
The blog post failed to point out that the Objective-C developer that wrote this macro in the first place should have been shot in the head with a Nerf gun and sent back to junior school. There is so much wrong with that macro, I don’t want to waste any more of my life discussing it.
I don’t condone or encourage the use of macros in Objective-C where functions or constants could be used instead, and I don’t think that any other iOS developer should do so either. And I certainly don’t think the Objective-C community should be encouraging this by promoting or linking to this type of blog post.
There is never a need to write a function-like macro in Objective-C. If you’re worried about performance (of calling out to a function), then there’s no need. Cocoa provides the macros
CF_INLINE, etc. which mean that your friend the compiler will decide whether it’s appropriate to expand the function definition in-line. See the definition of the
CGRectMake function for example. And there is certainly no need to
#define primitive constants!
Yet even Apple’s documentation seems to condone the use of primitive constants being declared as a macro. By the time I read this, I was getting pretty fed up. Why is everyone, including Apple, encouraging the misuse of macros?!
Apple’s example below should never have been written as a macro in the first place.
It provides no type-safety and it won’t be available to interrogate in the debugger. There’s a real danger this type of macro could be misused and lead to hard-to-diagnose bugs. In short, it’s code smell that should be avoided at all times, with no excuses.
So are macros ever acceptable?
Some people would probably argue the fact that it’s never acceptable to use macros. I would encourage those people to read on because you might discover some cool tricks!
I wrote recently about KVC collection operators and how to use them safely. In that post, I discuss the use of macros to provide compile-time checking on the keys used in key-value coding.
Consider the following example interfaces:
1 2 3 4 5 6 7 8
I can use KVC collection operators to simplify retrieval of transaction characteristicts from an array of
Transaction * objects:
1 2 3 4
I haven’t used a macro yet! But I can use macros as defined in my other post to perform these operations and get compile-time checking of the key paths with code-completion and syntax highlighting! (The highlighter on my blog doesn’t display it as nicely as Xcode does.)
1 2 3
Notice that the key paths are not enclosed in quotes. This is due to how they are expanded at compile time to be verified and then turned into strings to pass to
So a macro that adds compile-time validation and code-completion to an otherwise crash-prone interface is, in my opinion, a decent example of when to use macros in Objective-C.
How does this type of macro translate to Swift?
In the macros above, we pass the type expected in the array, namely
Transaction * and pass the key path that we want to extract. In Swift, the type of objects in an array is mandatory when you declare the array, and we can extract information using the
For example, the above can be re-written in Swift as follows:
1 2 3
But you could easily argue that the above is a little long-winded, in which case you could simplify it by extending
Array. I’ve shown how to do this for the
minimum below, but it could be easily modified for
1 2 3 4 5 6
In the above extension, I’m defining the
mapMinimum function, which can be invoked on an array whose members all conform to the
Comparable protocol (in order to be passed into the
max function). It returns the minimum of the members of the array resulting from calling
transform(x) on all members
self. In other words, it performs the
map function with the given closure, and then returns the minimum of the resulting array.
Having declared the same for maximum, I can now use them as follows:
So the syntax is actually improved in Swift compared to the macros I defined in Objective-C. The key path is validated by the compiler, because it knows what types of object are contained in the
I’ll be investigating more of what I consider “valid” uses of macros and how we can achieve the same result using the advanced language features of Swift.
If you’ve enjoyed reading this article, please follow me on twitter or subscribe to my RSS feed for more of the same. I’m happy to discuss this or any other subject in more depth, so feel free to contact me!