One more important tidbit that I forgot to add... Once creating a wrapper class or classes that fully encapsulate all calls from Swift to any older library functions originally written in C, you can then treat the wrapper class(es) as a definite abstraction boundary, upon which you can utilize all parts of Swift (including optionals) by dealing directly and exclusively with the wrapper class(es) alone. The wrapper class or classes are written specifically to isolate all calls into some older C-based library whose functions are now accessible from Swift, but that still adhere to C-like constructs (e.g
within a function's signature (the list of parameters and their associated types, that describe the ordering and types of values needed to be supplied to the function within any valid call).
You can recognize the older C-based functions by their signature which should resemble the general form of signatures utilized for the AudioToolbox functions
func MusicTrackSetProperty(_ inTrack: MusicTrack,
_ inPropertyID: UInt32,
_ inData: UnsafeMutableRawPointer,
_ inLength: UInt32) -> OSStatus
A clear giveaway that the library still utilizes the conventions of C, is apparent whenever you see a type like "UnsafeMutableRawPointer" or something similar, as a type directly within a function's signature. It's also obvious that an older C-based implementation is being used still behind the scenes, if there's no surrounding class, only a set of individual functions that are grouped together by file, toolbox, and/or documentation only (i.e
. there's NO parent class to host the functions, making them methods instead).
Happy (lower-level) Swifting !