Archive for May 20, 2016

Friday, May 20, 2016 [Tweets] [Favorites]

Swift Assertions

Andy Bargh:

If we dive into a bit more of the detail behind assertions in Swift, we find that the Swift language actually supports five, different types of assertion. These are:

Each of these assertions behave slightly differently and in the majority of cases the optimisation level that the code is compiled with has a direct effect on whether they are evaluated or not.

Update (2017-03-15): Previously: precondition vs. assert in Swift.

Testing IBOutlets and IBActions With Curried Functions in Swift

Ben Chatelain:

Currying helps to simplify these outlet and action test functions so that the view controller doesn’t have to be passed in every function call. Just like the sumA function holds onto the value of the first parameter, these test functions hold onto a reference to the view controller being tested. There’s also the benefit of being able to give the returned function a very readable name.


So, what is that hasButtonOutlet magic? It’s a partially-applied function saved in a local variable.


Shortly after @allonsykraken posted Hipster Swift, I learned that the super-clean syntactic sugar version of curried functions is going away in Swift 3 and it made me sad.

Code Coverage From the Command Line With Clang

Alastair Houghton:

Having searched the Internet several times to find out how to get coverage information out of clang, I ended up feeling rather confused. I’m sure I’m not the only one. The reason for the confusion is fairly simple; clang supports two different coverage tools, one of which uses a tool with a name that used to be used by the other one!


In both cases, you need to pass the coverage options to the clang or clang++ driver when you are linking as well as when you are compiling. This will cause clang to link with any libraries required by the profiling system. You do not need to explicitly link with a profiling library when using clang.

Separate, Support, Serve

Benjamin Pollack:

I want to do two things in this blog post: convince you that Embrace, Extend, Extinguish is a grossly invalid understanding of Microsoft’s strategy; and convince you that an alternative strategy of Separate, Support, Serve provides a much better lens to view the modern Microsoft.


First, Microsoft has to enable me to even use Microsoft technology in the first place. If Microsoft keeps tying all Microsoft technology to Windows, then they lose. If I have to use Windows to use SQL Server, then I’ll go with PostgreSQL. If I have to use Windows to have a sane .NET server environment, then I’ll pick Java. To fix that, Microsoft needs to let me make those decisions separately.

That’s indeed the first phase of their strategy: separating Windows from the rest of their technologies. SQL Server is available on Linux not to encourage lock-in, but because they need you to be able to chose SQL Server even though you’ve got a Docker-based deployment infrastructure running on RedHat. .NET is getting great runtimes and development environments (Visual Studio Code) for Unix so that I can more reasonably look at Azure’s .NET offerings without also forcing my entire dev team to work on Windows. This strategy dramatically increases the chance of me paying Microsoft money, even though it won’t increase the chance I’ll use Windows.