A result type (based on swiftz) that can represent either an error or success:
enum Result<X, T> {
case Err(() -> X)
case Ok(() -> T)
}
Now we need a way to chain multiple results together without lots of nesting of if statements -- or exceptions. To do so, we can define a new bind (result, next) operator (implementation borrowed from swiftz) that operates on Result types (a.k.a flatMap or >>=):
Err, the result is immediately returned.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| import Foundation | |
| extension String | |
| { | |
| var length: Int { | |
| get { | |
| return countElements(self) | |
| } | |
| } | |
| #!/usr/bin/env ruby | |
| device_types_output = `xcrun simctl list devicetypes` | |
| device_types = device_types_output.scan /(.*) \((.*)\)/ | |
| runtimes_output = `xcrun simctl list runtimes` | |
| runtimes = runtimes_output.scan /(.*) \(.*\) \((com.apple[^)]+)\)$/ | |
| devices_output = `xcrun simctl list devices` | |
| devices = devices_output.scan /\s\s\s\s(.*) \(([^)]+)\) (.*)/ |
| // | |
| // shuffle.swift | |
| // | |
| // Created by Guillaume Lessard on 2014-08-28. | |
| // Copyright (c) 2016 Guillaume Lessard. All rights reserved. | |
| // | |
| // https://github.com/glessard/shuffle | |
| // https://gist.github.com/glessard/7140fe885af3eb874e11 | |
| // |
| #!/usr/bin/perl -w | |
| use strict; | |
| # Makefile generator for quick compilation of Swift projects | |
| # By: Roopesh Chander | |
| # Thanks: Andy Matuschak | |
| # Works only for swift-only projects. | |
| # Usage: | |
| # > perl makemake.pl | |
| # > make |
| #!/usr/bin/env python3 | |
| """Simple HTTP Server With Upload. | |
| This module builds on BaseHTTPServer by implementing the standard GET | |
| and HEAD requests in a fairly straightforward manner. | |
| see: https://gist.github.com/UniIsland/3346170 | |
| """ | |
| import Cocoa | |
| struct Person { | |
| var name: String = "John" | |
| var age: Int = 50 | |
| var dutch: Bool = false | |
| var address: Address? = Address(street: "Market St.") | |
| } | |
| struct Address { |
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post: