More Swift Attributes
Use this one weird trick
Swift has a variety of little documented (or undocumented) attributes just sitting there waiting to be used. Let's look at a few of them:
@inline
This attribute gives the compiler inlining hints. The valid values are __always
and never
. I don't think I'd use this one (especially __always
) unless I was absolutely certain I needed it; the rules around it are not currently known. In limited testing it seems to work but YMMV.
edit: To further explain: though LLVM has the concept of forced inlining, we don't currently know if this attribute actually maps to that directly. Nor do we know if there are size limits that will cause the compiler to ignore this and skip inlining. In theory it should have this behavior but I'm not going to promise anyone that it does.
Note that @inline
attributes are ignored in debug builds (when optimizations are turned off).
@transparent
I originally left this one out of the list. It causes the compiler to inline the function much earlier in the pipeline. It is intended for "very primitive functions like +(Int, Int)" that should "never be emitted as independent functions".
@transparent
functions are inlined even in debug mode with no optimizations, so things like 1 + 1
aren't horribly slow function calls. Otherwise it works very similarly to @inline(__always)
.
@availability
This attribute marks things as only available on certain platforms or in certain versions. The first parameter is the platform. Can be *
for all, iOS
, or OSX
. You can specify multiple @availability
attributes if necessary for different platforms.
The second parameter can be unavailable
which indicates that this item is not available at all on the given platform. Otherwise you can specify a combination of one or more versions: introduced
, deprecated
, and obsoleted
. Obsoleted means the item was removed, deprecated just means it will give a warning if used. Lastly you can specify message
which will be output by the compiler if the item is used. Some examples:
@availability(*, unavailable)
func foo() {}
@availability(iOS, unavailable, message="you can't call this")
func foo2() {}
@availability(OSX, introduced=10.4, deprecated=10.6, obsoleted=10.10)
@availability(iOS, introduced=5.0, deprecated=7.0)
func foo3() {}
@noreturn
Just like it says: the compiler can assume this function is either the beginning of an eternal run loop, while true { }
, or it aborts or exits the process.
Edit: Commenter Marco Masser points out that the compiler will ignore missing return values in a function if you call another function marked @noreturn
because it understands the control flow.
@asmname
Gives the symbol name for the function, method, or property's implementation. If you can figure out the parameters and their types then this will let you call internal Swift standard library functions... or even C functions for which you don't have the headers handy: @asmname("function") func f()
@unsafe_no_objc_tagged_pointer
This one is still a mystery but my guess is it tells Swift not to use tagged pointers when bridging to Objective-C.
@semantics
Yet another mystery. The parameters seem to be strings like array.mutate_unknown
or array.init
. Presumably this gives the compiler (or the static analyzer) information about how the function behaves.
Conclusion
Who needs boring old @objc
or @autoclosure
? Get out there and live a little.
In administrative news I will be at WWDC this year. I hope to see you there!
This blog represents my own personal opinion and is not endorsed by my employer.