IanKeen

import Foundation

class DictionaryDecoder {
    init() { }
    
    func decode<T: Decodable>(_ type: T.Type, from data: [String: Any]) throws -> T {
        let decoder = _Decoder(codingPath: [], source: data)
        return try T(from: decoder)
    }
}

andymatuschak

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

blixt

import UIKit

extension String {
    var hexColor: UIColor? {
        let hex = self.stringByTrimmingCharactersInSet(NSCharacterSet.alphanumericCharacterSet().invertedSet)
        var int = UInt32()
        guard NSScanner(string: hex).scanHexInt(&int) else {
            return nil
        }
        let a, r, g, b: UInt32

oleganza

Async semantics proposal for Swift

Modern Cocoa development involves a lot of asynchronous programming using blocks and NSOperations. A lot of APIs are exposing blocks and they are more natural to write a lot of logic, so we'll only focus on block-based APIs.

Block-based APIs are hard to use when number of operations grows and dependencies between them become more complicated. In this paper I introduce asynchronous semantics and Promise type to Swift language (borrowing ideas from design of throw-try-catch and optionals). Functions can opt-in to become async, programmer can compose complex logic involving asynchronous operations while compiler produces necessary closures to implement that logic. This proposal does not propose new runtime model, nor "actors" or "coroutines".

Table of contents

rnapier

// This is pretty clean, but I often dislike chains of temporary variables
// They tend to lead to little bugs when you use the wrong one. Swift's warnings
// and 'let' reduce problems, though.
func pagesFromOpenSearchData(data: NSData) throws -> [Page] {
    let json = try NSJSONSerialization.JSONObjectWithData(data, options: NSJSONReadingOptions())

    guard      let array  = json as? [JSON]                 else { throw JSONError.BadArray(json) }
    guard case let value  = array[1] where array.count >= 2 else { throw JSONError.OutOfRange }
    guard      let titles = value as? [String]              else { throw JSONError.BadStringList(json) }