Migrating ifs to guards in Swift | Hacker News Reader

Migrating ifs to guards in Swift

ericasadun.com

63 pointsingve21 comments

I've recently started writing code (for an OS X app) in Swift, and I find the guard statement truly fantastic. Many of my methods do very little except test for preconditions, and the "guard" statement makes this very clear. For example, my action methods all look like this:

    @IBAction func doSomething( sender: AnyObject ) {
       guard ... else { NSBeep(); return }
       guard ... else { NSBeep(); return }
       guard ... else { NSBeep(); return }
       
       mutateState()
    }

There's now a clear separation between the part that just checks preconditions, and the part that does something. It's really nice for defensive programming, and makes it easy to write programs that do not crash.

Yeah, guard is awesome, especially for making arguments from optionals to regular(?) variables.

But you kinda had that "guard" with NSAssert() in DEBUG. In fact all methods should have NSParameterAssert() for mandatory arguments before recent Obj-C additions. You could written your own assertion to work in production and do a beep and return.

> making arguments from optionals to regular(?) variables.

The customary way of saying that is “unwrapping optional arguments”.

Haha yeah, it just slipped my mind. Thanks. Knew something was off.

https://github.com/Microsoft/CodeContracts

Takes this to another degree for .Net. Enables deeper static analysis to catch more programming errors before runtime.

Language features like guard have improved the robustness of my production Apps. Eventually Swift forces you to unwrap your optionals, and this encourages you to inspect them more closely.

I wonder if guards are somehow related to branch prediction hints. E.g. guard else statement should be considered less likely than the happy path.

I don't understand what purpose the "guard let x = x where x > 0 else {}" achieves for the compiler. Couldn't it have been designed to be "guard x > 0 else {}" and achieve the same goal?

In this case, x is an optional, eg. Int? (if you are unfamiliar with Swift, this means either an Integer or the special value nil)

"guard let x = x where x > 0 else {}" first unwraps the optional (check if it is not nil), then it checks if the value is greater than 0.

This is the nice thing about "guard let ...". Below the guard statement, x is no longer an optional.

Also, the code inside the else{} block is required to leave the current scope (e.g. return from the method, fatalError(), assert(false), etc.). In that way, 'x' will always contain a valid value after the guard statement, or statements after the guard statements will not execute.

Ah, that makes sense. Thanks!

Is there an analog to guard in other languages?

Erlang has guard sequences, also a "when" clause: http://erlang.org/doc/reference_manual/expressions.html#id83...

"design by contract" is the general term [see http://c2.com/cgi/wiki?DesignByContract]. d and racket have excellent support for it

https://dlang.org/spec/contracts.html http://docs.racket-lang.org/guide/contracts.html

and here's a library to add it to ruby (i've seen a couple of others floating around): https://egonschiele.github.io/contracts.ruby/

I can't help but feel sorry for ex-objective-c developers who think they are getting it good with Swift.

Care to elaborate?

I think he's referring to more mature languages like C#. Many features which are just now being introduced in Swift have existed for over a decade in .NET languages. Everything old is new again...

I would love to see something like LINQ make it into Swift.

If only that was enough, but C# has been playing catch up on F# for the last three revisions (the last one still being worked on) and will likely never catch up.

When a giant like Apple gives itself a clean slate to work on designing a new language, it's die-hard fans deserve better than the rag tag mess the OP has to get into and yet can't help but simply be satisfied with respect to what he had to deal with before.

"Many features which are just now being introduced in Swift have existed for over a decade in .NET languages."

And nobody but insecure people give a crap. The rest of us just want to use good tools to get our jobs done.

With Microsoft's recent push to make technologies like the .NET CLR, C#, ASP.NET, and so on available on non-Windows platforms (such as Linux and OS X), this does become a factor for a great many more developers.

On one hand, we can choose a younger, less-mature language/platform like Swift. On the other, we can choose C# and .NET, even if we're not targeting Windows, and get a very mature and capable language with a superb standard library, and a very large existing user community.

Whether they like it or not, Swift and its community will have to compete with what .NET offers. As it currently stands, Swift is likely on the losing end of many of these competitions in many cases. Will this change in the future? Perhaps. But it will take a lot of effort from the Swift team and its supporters.

Don't get me wrong, Swift is a fantastic improvement over Obj-C. I am an iOS developer by trade and it makes my life much better. However, in a past life I worked with C#, and still find myself yearning for some of its features.

One area Apple has a huge leg up is its API design. All of Apple's frameworks are well thought out and easy to use. Microsoft, not so much. One glaring example is Bluetooth: CoreBluetooth is a straightforward abstraction, whereas Microsoft's is a total Frankenstein shit show.

Reply on news.ycombinator.com