In this article, I'll discuss the Result type in Swift as well as common variations in implementation and approach used for this data type. I'll also look at *why* the type was rejected for inclusion in the standard library and what effect that rejection is likely to have.
One of the most annoying problems in Swift is when the compiler gives an 'Expression was too complex to be solved in a reasonable time' error. I look at why this error occurs, how to avoid it and talk about how this should be solved in a future compiler update.
Fun with a pushdown automaton (implemented as a single mighty switch statement) for parsing whitespace in Swift source files. The result is an Xcode 8 Source Editor Command extension for detecting and correcting whitespace issues in Swift files.
I'm going to talk about the absence of any threading or thread synchronization language features in Swift and the concurrency proposal for Swift's future. I'll also try to get a wrapper around different mutex machinery to perform optimally.
In my first truly 'Cocoa' article since restarting Cocoa with Love, I'll talk about presenting errors to the user. In particular, ensuring that errors we didn't expect or plan for are presented in a manner that allows error reporting by users and easier bug fixing.
In an ideal world, we would not know if our code was indented with either tabs or spaces. Remember: the moment you become aware of how your code indentation is encoded, you're not programming, you're managing your programming tools.
Struct types are not usually heap allocated, reference counted or able to perform work on deallocation. You can coerce them into having these properties but careful if you do: it can be a source of memory leaks, errant behavior and compiler crashes.