Warning: some assembly required
Previously, I did a horrible thing by hooking up to a Swift internal library function then probing to determine its arguments.
In today's post I want to cover how I went about doing that. Perhaps it will help you in your debugging adventures.
Taking the Dump
The first step is to dump the dylib exported symbols so we can go sifting for . . .
Delicious partial function application
If you aren't familiar with Function Currying, the concept is fairly simple. Imagine you have some method that takes 4 arguments. If the function is curried, then the first function takes argument #1 and returns a function that takes argument #2. That function takes argument #2 and returns a function taking argument #3. This continues . . .
The more things change
In the fast-moving world of Swift, I'm a day late and that might as well be a year. But I'm also a developer so I just can't help myself. Let's dive into the changes in Beta 5!
- As expected, the null coalescing operator was added
??and lazily evaluates the right-hand side again as you'd expect.
- Optionals no . . .
Don't do this; code responsibly
Please don't do this. It's horrible, unsupported, and may crash your program.
That said, let's demangle a class name by calling an internal Swift library function.
@asmname("swift_demangleSimpleClass") func demangleSimpleClass(mangledName: ConstUnsafePointer<Int8>, moduleName: UnsafePointer<Int>, className: . . .
There's an awful joke in here somewhere
David Owens II writes about Swift access control and unit tests. He's currently adding his source files directly to the unit test target so the internal members are visible to the tests.
That's probably the best solution possible currently, but I'm filing a radar to add the equivalent of
InternalsVisibleTo. In C#, that attribute . . .
Who wants to live without extensions
Optionals are great, but there are some improvements that might make code clearer and more explicit. I also want to acknowledge that in some cases you don't actually care if the value is nil or not, you just want to provide an alternate value if it is; that's usually called the null coalescing operator, but Swift doesn't currently . . .
Abandon all hope of safety
Update: I originally did not make it clear but if Swift knows the type of the unsafe pointer then arithmetic will operate on
sizeof(T) not on bytes! The same goes for
alloc. So my example below with an
UnsafePointer<Float32> will jump forward
25 * sizeof(Float32) bytes.
I've seen a lot of people wondering how to do raw pointer . . .