If you are anything like me, you were not very pleased with the print() and println() changes. While working on some other items, I realized that it's possible to shadow global functions with your own. This means that we can fix the print() and println() functions. Yay!

func print<T>(value: T, appendNewline: Bool = false) {
    Swift.print(value, appendNewline: false)
}

func print<T, TargetStream : OutputStreamType>(value: T, inout _ target: TargetStream, appendNewline: Bool = false) {
    Swift.print(value, &target, appendNewline: false)
}

func println<T>(value: T, appendNewline: Bool = true) {
    Swift.print(value, appendNewline: true)
}

func println<T, TargetStream : OutputStreamType>(value: T, inout _ target: TargetStream, appendNewline: Bool = true) {
    Swift.print(value, &target, appendNewline: true)
}

Agh! Back to sanity (at least for me).

P.S.

• I logged a bug about the behavior here: http://openradar.appspot.com/21577485.
• Full source for the above workaround can be found here: swift-fix.

Previously I was wondering how to test precondition() and assert() in my code. Well, Nikolaj Schumacher suggested something clever: shadow the precondition() and assert() functions.

My implementation his suggestion can be found here: https://github.com/owensd/swift-fix/blob/master/Assertion.swift. There is still a slight problem with this version though: normally precondition() and assert() will terminate the execution of the function, but unless you use my throwing version of those functions, your code path will continue to execute. This may or may not be a problem for you, so beware.

But wait… if we can shadow the functions and replace them with our own implementations, then this means that method swizzling is back on the table!

Here's an example:

Let's say, we have a scenario, where isEmpty on an array is just utterly broken. Too bad for us, right? Well… not exactly.

extension Array {
    var isEmpty: Bool {
        print("monkey patch!")
        return false
    }
}

let a: [Int] = []
a.isEmpty           // guess what this outputs? =)

Now, there is a caveat here… I don't know how to call the base implementation, so you're stuck with re-implementing the entire thing for member functions. For global functions though, we can fully qualify them to explicitly get the version we want.

Maybe someone else knows how to do that part?

Update, later that evening…

So, it turns out this really only works for the following:

1. Global functions
2. Properties on non-@objc types.

Oh well, and interesting hack. It does seem strange that some things can be shadowed and other things cannot.

I have a bit of a design conundrum. I have an API that looks like this:

public func next(index: ContentType.Index?) throws -> TokenizerResult<ContentType>? {
    precondition(rules.count > 0, "There are no rules specified for your tokenizer.")
    // ...
}

This belongs on a protocol Tokenizer and a default implementation is provided in an extension. The rules are static per type, at least in the default case.

So… the problem? I cannot write a test for this code because precondition fails with an uncatchable runtime exception. What I really want is a type ArrayOfOneOrMore<Element>. However, this requires a lot of code and method forwarding to work; I don't want to do that.

It seems my options are:

1. Be ok with not being able to write a test for this.
2. Relax the condition, but this hides a logical implementation error.
3. Do all of the work to implement ArrayOfOneOrMore<Element>.

Is there another option I'm missing?

Update July 9th, 2015

So I've been thinking about this some more. There is a workaround that can be done: change precondition() to assert() and compile out the assertions in a new Debug-unchecked build for testing. This keeps all of the good debugging symbols and optimizer changes at bay while still allowing for testing your code flow.

Steps to get this to work:

1. Create a new build config Debug-unchecked
2. Change the Other Swift Flags (OTHER_SWIFT_FLAGS) compiler options to -assert-config Release
3. Change precondition() to assert()
4. Update your code to handle the code path for the error state

   public func next(index: ContentType.Index?) throws -> TokenizerResult?

   assert(!rules.isEmpty, "There are no rules specified for your tokenizer.")
   		if rules.isEmpty { throw TokenizerError.NoTokenizerRulesPresent }  
   		  // ...
   		

   }

This has the benefit of raising the error immediately on failure for debug builds, providing a testing path, and still providing the error in a catchable way in release builds.

Of course, if I do this a lot, I'll probably just do this:

public func next(index: ContentType.Index?) throws -> TokenizerResult<ContentType>? {
      try assert(!rules.isEmpty, "There are no rules specified for your tokenizer.", TokenizerError.NoTokenizerRulesPresent)
      // ...
}

And create these helpers that I just use all the time:

func assert(@autoclosure fn: () -> Bool, _ error: ErrorType) throws {
    return try assert(fn, "", error)
}

func assert(@autoclosure fn: () -> Bool, _ message: String, _ error: ErrorType) throws {
    let result = fn()
    assert(result, message)
    if !result { throw error }
}

At least with these helpers it's no extra work for me. The biggest drawback I see is that it requires compiling my code again, which could suck.

Now that we have some proper error handling measures, I've been having a bit of a rough time deciding between init? and init() throws.

What I've come to realize is, my problem is really about the callsite, I actually always want to use throws. The simple fact is that I can return more information about the failure and let the caller decide if they care about it or not.

Here's an API that currently uses init?() that I think would actually value from providing the failure reason instead of just a blanket nil.

/// Construct from an ASCII representation in the given `radix`.
///
/// If `text` does not match the regular expression
/// "[+-][0-9a-zA-Z]+", or the value it denotes in the given `radix`
/// is not representable, the result is `nil`.
init?(_ text: String, radix: Int = default)

Ok, back to my usage problem example:

enum Error : ErrorType {
    case NotImplemented
}

struct Foo {
    init?(failable: Int) { return nil }
    init(throwable: Int) throws { throw Error.NotImplemented }
}

func example1() {
    guard let f = Foo(failable: 0) else {
        print("error")
        return
    }

    print("Foo(failable:) creation passed")
}

func example2() {
    do {
        let t = try Foo(throwable: 0)
        print("Foo(throwable:) creation passed")
    }
    catch {
        print("error: \(error)")
    }
}

example1()
example2()

The throws version really sucks in comparison. It's especially egregious because I'm going to be handling the failure case in exactly the same way.

Ok, so let's make it better:

func trythrow<T>(@autoclosure fn: () throws -> T?) -> T? {
    do { return try fn() }
    catch { return nil }
}

func example3() {
    guard let tt = trythrow(try Foo(throwable: 0)) else {
        print("error")
        return
    }

    print("Foo(throwable:) creation passed")

}

example3()

This gets us into a happy place again. We can turn failures where we do not care about the specific reasons into a code path that is more natural. If this becomes a pattern, it begs the question why this wouldn't be just built into the language.

Enter try?.

See this thread for some more great discussion.

// this won't compile, hypothetical syntax
func example4() {
    guard let tt = try? Foo(throwable: 0) else {
        print("error")
        return
    }

    print("Foo(throwable:) creation passed")
}

example3()

I think this is a big win. Note that while this appears to be encouraging one to ignore errors, it in fact doesn't. Many types we only care that a failure happened. This syntax simply reduces the complexity of the code when that is the case.

Also, try? is very searchable so it is trivial to audit your code for all of the uses of it to ensure error handling is indeed not needed in a fuller form.

Finally, because an Optional<T> is being returned, you are still forced into unwrapping it in order to use it.

I like it. Until we get it, trythrow() is going to be my goto.

P.S. Someone already logged rdar://21692462 on it. Great!

So I've had this project on my mind for a few months now: Swift script management system. While I was doing the planning for it, I was dreaming big… like how could we replicate the Python system.

That's a lot of work though… and I had other things going on. And really, who would want to use it besides just me?

Then I saw this talk by Ayaka Nonaka and thought to myself, "OK, maybe people would actually like to have something like this."

Instead of going big, I figure I'd just start small and do it the hackiest way possible: concat files together and call it good!

So if you're looking for a way to write Swift scripts and manageme dependencies, check out Apous.

There is a post about using structs or classes in Swift here: Should I use a Swift struct or a class?. If you like functional programming or reducing state mutations, be warned, it's somewhat antagonistic to your position.

The fundamental problem I find with the piece is that it creates a false selection of choices to the problem statement posed while misrepresenting much of the advice about chosing when to use value types. I think it also confuses the purpose of the proposed "inner class device".

1. We have a protocol defined as:

protocol CanSend {
    typealias Message
    func send(messgage: Message) throws
}

2. We need to implement this protocol in two manners: one that mutates and one that does not.

Specifically, the desire is to create a MockServer<T> that can be used to keep track of state for testing. Ok, this sounds reasonable. So the following is presented:

struct MockSender<T> {
    var sentMessages: [T] = [] //you inspect this property to study 
    //what messages were previously sent for unit test purposes
}

extension MockSender : CanSend {
    typealias Message = T
    func send(message: T) {
        self.sentMessages.append(message) //error: Immutable value 
        //of type '[T]' only has mutating members named append
    }
}

This, as pointed out, does in fact present a problem. The protocol function send is not marked as mutating yet the implementation clearly attempts to mutate itself.

However, this is the conclusion that is drawn:

Right, so the problem is our protocol says the function is non-mutating, but in reality it needs to be mutating.

So we go change the protocol, right? I mean after all, by definition this program has no legacy code, so we can structure the protocol however we want.

After some clammering about how this is the wrong approach, which I agree, there is no need to mark the function as mutating, we get to this conclusion:

We can solve this problem with a device called an "inner class", which you probably have already seen, but if you haven't just imagine that there is some god-awful way to create a mutating implementation of a non-mutating func, and we will cover the details later.

This, is actually the wrong conclusion. The entire purpose of the "inner class" is to provide value semantics while maintaining effeciency of implementation. In addition to that, if some of the quoted advice in the article had been followed with regards to struct usage, a different conclusion would have presented itself. Let's look at this piece of advice:

Don't use classes when structs will do. Use classes if you want reference types. Use structs if you want value types. You can add functionality to both (and to enumerations) in Swift. When in doubt, err on the side of value types. If your construct doesn't have a life cycle, or two constructs with similar values should be considered as the same thing, use a struct. (Do take advantage of Swift structs. They're neat.)

I emphasized the interesting bit from there.

You see, MockSender<T> does indeed have a lifecycle; it has a history of all messages sent that varies over time.

Also, this piece of advice:

Unless you require functionality that can only be provided by a class (like identity or deinitializers), implement a struct instead… Rationale: Value types are simpler, easier to reason about, and behave as expected with the let keyword.

In addition to that, we have a protocol in which we do not want to enforce a mutation contract across all conforming types. A class provides us the functionality that only it provides. So why not simply follow the advice and create this version instead?

{} class MockSender

var sentMessages: [T] = []

}

extension MockSender : CanSend

typealias Message = T
func send(message: T) {
    self.sentMessages.append(message)
}

}

This solution does exactly what we want. It also does it by maintaining the protocol can be conformed by immutable value-types and my mutable reference types. This is a validation of the "Structs Philosophy‚Ñ¢"; `MockServer<T> is not a value-type, don't try and make it one. 

The problem with the first example is that, in my opinion, the author conflated two separate things: the desire to create a value type and the usage of inner classes in value types for performance reasons. If, we really wanted immutable value-types from the protocol and allow state changes, the protocol should have been defined as such:

protocol CanSend

typealias Message
func send(messgage: Message) throws -> Self

}

The weird part about the piece is that we end with the conclusion that we should have just started with, and that conclusion isn't in disagreement to much of the advice out there about starting with a struct and move to a class when/if necessary: 

> In all other cases, define a class, and create instances of that class to be managed and passed by reference. In practice, this means that most custom data constructs should be classes, not structures.

So...

 - Yes, make your `MockServer<T>` a class.
 - No, do **not** write the "struct with inner class wrapper" so you can simply make it pseudo-mutable.
 - You should still start with the question: is my type a value-type or a reference type? This is also the advice from Apple.

 **Update Sunday, July 5th @ 4:03PM**
 Here's a follow-up [conversation thread](https://gist.github.com/drewcrawford/752b2bfef7d8574eab01).

Ever since Swift has debuted, there's been a bit of a fuss about how it can be used for scripting. Yes, yes it can, but so can every other language that has an interpreter, or more accurately, a binary that can do something with the input file.

In fact, we can even make such a thing for C.

Here is what our little "c script" will look like.

#!/path/to/cscript

#include <stdio.h>

int main() {
    printf("I want to be a cool kid too!\n");
}

Now, the astute among you may have noticed something… the magic SHEBANG (#!) is, well, it is currently pointing to some magic place.

I've actually created a little tool to help us out (of course it's in Swift!).

import Foundation

let path = NSProcessInfo.processInfo().arguments[1]
let code = try NSString(contentsOfFile: path, encoding: NSUTF8StringEncoding)

let newCode = code
    .componentsSeparatedByString("\n")
    .filter { $0.rangeOfString("#!/") == nil }
    .reduce("") { $0 + $1 + "\n" }

try newCode.writeToFile("_script.c", atomically: true, encoding: NSUTF8StringEncoding)

var task = NSTask()
task.arguments = [ "_script.c", "-o", "_script" ]
task.launchPath = "/usr/bin/clang"
task.standardOutput = NSFileHandle.fileHandleWithStandardOutput()
task.standardError = NSFileHandle.fileHandleWithStandardError()

task.launch()
task.waitUntilExit()

var script = NSTask()
script.launchPath = "_script"
script.standardOutput = NSFileHandle.fileHandleWithStandardOutput()
script.standardError = NSFileHandle.fileHandleWithStandardError()
script.launch()
script.waitUntilExit()

try NSFileManager.defaultManager().removeItemAtPath("_script.c")
try NSFileManager.defaultManager().removeItemAtPath("_script")

First, compile that Swift code into an executable cscript. Next, modify the #! reference in your C source to point to this new cscript tool. Finally, be sure to chmod +x on the

"c script" file.

Then, it's simply a matter of running it like any other script:

> ./script.c
I want to be a cool kid too!

Anyhow, I just wanted to point out that this is not some black-magic that Swift is doing; it is simply a by-product of the Swift REPL environment. This is just one of the great things about our lovely OS X being backed by a unixy foundation.

Update June 27th @ 3:21 PM

I was able to squeeze out some more performance by promoting some constants that I noticed I had in my code.

Here's the updated code:

func RenderGradient(inout buffer: RenderBuffer, offsetX: Int, offsetY: Int) {
    buffer.pixels.withUnsafeMutableBufferPointer { (inout p: UnsafeMutableBufferPointer<Pixel>) -> () in
        var offset = 0

        let yoffset = int4(Int32(offsetY))
        let xoffset = int4(Int32(offsetX))

        let inc = int4(0, 1, 2, 3)
        let blueaddr = inc + xoffset

        for var y: Int32 = 0, height = buffer.height; y < Int32(height); ++y {
            let green = int4(y) + yoffset

            for var x: Int32 = 0, width = buffer.width; x < Int32(width); x += 4 {
                let blue = int4(x) + blueaddr

                // If we had 8-bit operations above, we should be able to write this as a single blob.
                p[offset++] = 0xFF << 24 | UInt32(blue.x & 0xFF) << 16 | UInt32(green.x & 0xFF) << 8
                p[offset++] = 0xFF << 24 | UInt32(blue.y & 0xFF) << 16 | UInt32(green.y & 0xFF) << 8
                p[offset++] = 0xFF << 24 | UInt32(blue.z & 0xFF) << 16 | UInt32(green.z & 0xFF) << 8
                p[offset++] = 0xFF << 24 | UInt32(blue.w & 0xFF) << 16 | UInt32(green.w & 0xFF) << 8
            }
        }
    }
}

And the new timings with this update:

Language: Swift, Optimization: -O, Samples = 10, Iterations = 30          ┃ Avg (ms) ┃ Min (ms) ┃ Max (ms) ┃ StdDev ┃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━┩
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD))                 │ 15.75163 │ 15.00523 │ 17.31266 │ 0.8139 │
──────────────────────────────────────────────────────────────────────────┴──────────┴──────────┴──────────┴────────┘

Language: Swift, Optimization: -Ounchecked, Samples = 10, Iterations = 30 ┃ Avg (ms) ┃ Min (ms) ┃ Max (ms) ┃ StdDev ┃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━┩
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD))                 │ 3.789642 │ 3.272549 │ 5.110642 │ 0.6232 │
──────────────────────────────────────────────────────────────────────────┴──────────┴──────────┴──────────┴────────┘

The -O case was unaffected, however, the -Ounchecked is now about twice as fast as before and practically the same as the C

Update June 27th @ 1:56 AM

I noticed a bug that I had when adding the x-values, they should have been incremented by (0, 1, 2, 3). I updated the code samples and timings, though the analysis comes out to be roughly the same. I did see some the SIMD code not have much benefit under the most aggressive compiler settings. That's not too unexpected as this code is fairly trivial.

Original Entry

Well, it's that time again, to look at the performance of Swift. I've been using my swift-perf repo which contains various implementations of a RenderGradient function.

So, how does Swift 2.0 stack up in Xcode 7 Beta 2? Good! We've seen some improvements in debug builds, which is great. There is still a long ways to go, but it's getting there. As for release builds, not too much difference there.

However, there is a new thing that got added in Swift 2.0 – basic SIMD support.

I decided to update my RenderGradient with two different implementations, one that uses an array of pixel data through the array interface and another that interacts with the array throught a mutable pointer. The latter is what is required for the best speed.

Here's the implementation:

NOTE: I'm pretty new to writing SIMD code, so if there are any things I should fix, please let me know!

func RenderGradient(inout buffer: RenderBuffer, offsetX: Int, offsetY: Int) {
    buffer.pixels.withUnsafeMutableBufferPointer { (inout p: UnsafeMutableBufferPointer<Pixel>) -> () in
        var offset = 0

        let yoffset = int4(Int32(offsetY))
        let xoffset = int4(Int32(offsetX))

        // TODO(owensd): Move to the 8-bit SIMD instructions when they are available.

        // NOTE(owensd): There is a performance loss using the friendly versions.

        //for y in 0..<buffer.height {
        for var y = 0, height = buffer.height; y < height; ++y {
            let green = int4(Int32(y)) + yoffset

            //for x in stride(from: 0, through: buffer.width, by: 4) {
            for var x: Int32 = 0, width = buffer.width; x < Int32(width); x += 4 {
                let inc = int4(0, 1, 2, 3)
                let blue = int4(x) + inc + xoffset

                p[offset++] = 0xFF << 24 | UInt32(blue.x & 0xFF) << 16 | UInt32(green.x & 0xFF) << 8
                p[offset++] = 0xFF << 24 | UInt32(blue.y & 0xFF) << 16 | UInt32(green.y & 0xFF) << 8
                p[offset++] = 0xFF << 24 | UInt32(blue.z & 0xFF) << 16 | UInt32(green.z & 0xFF) << 8
                p[offset++] = 0xFF << 24 | UInt32(blue.w & 0xFF) << 16 | UInt32(green.w & 0xFF) << 8
            }
        }
    }
}

The basic idea is to fill the registers on the CPU with data and perform the operation on that set instead of doing it one value at a time. For comparison, the non-SIMD version is below.

func RenderGradient(inout buffer: RenderBuffer, offsetX: Int, offsetY: Int)
{
    buffer.pixels.withUnsafeMutableBufferPointer { (inout p: UnsafeMutableBufferPointer<Pixel>) -> () in
        var offset = 0
        for (var y = 0, height = buffer.height; y < height; ++y) {
            for (var x = 0, width = buffer.width; x < width; ++x) {
                let pixel = RenderBuffer.rgba(
                    0,
                    UInt8((y + offsetY) & 0xFF),
                    UInt8((x + offsetX) & 0xFF),
                    0xFF)
                p[offset] = pixel
                ++offset;
            }
        }
    }
}

The awesome thing is that the SIMD version is a bit faster (update June 27th, @ 9:20 am : previously it was 2x before I fixed a bug, dang!)! When 8-bit operations are allowed, it should get even faster as we can reduce the amount of work that needs to be done even further and directly assign the result into memory.

Here is the performance break-down for these two methods in -O and -Ounchecked builds:

Swift Performance

Language: Swift, Optimization: -O, Samples = 10, Iterations = 30          ┃ Avg (ms) ┃ Min (ms) ┃ Max (ms) ┃ StdDev ┃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━┩
RenderGradient ([UInt32].withUnsafeMutablePointer)                        │ 18.07803 │ 17.19691 │ 21.00281 │ 1.4847 │
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD))                 │ 15.88613 │ 15.11753 │ 20.16230 │ 1.5437 │
──────────────────────────────────────────────────────────────────────────┴──────────┴──────────┴──────────┴────────┘

Language: Swift, Optimization: -Ounchecked, Samples = 10, Iterations = 30 ┃ Avg (ms) ┃ Min (ms) ┃ Max (ms) ┃ StdDev ┃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━┩
RenderGradient ([UInt32].withUnsafeMutablePointer)                        │ 6.623639 │  6.22851 │ 8.339521 │ 0.6325 │
RenderGradient ([UInt32].withUnsafeMutablePointer (SIMD))                 │ 6.629701 │ 5.930751 │ 8.751819 │ 1.0005 │
──────────────────────────────────────────────────────────────────────────┴──────────┴──────────┴──────────┴────────┘

Now, here's where things start to get really interesting. I have a C

C

Language: C, Optimization: -Os, Samples = 10, Iterations = 30             ┃ Avg (ms) ┃ Min (ms) ┃ Max (ms) ┃ StdDev ┃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━┩
RenderGradient (Pointer Math)                                             │    9.364 │    8.723 │   11.338 │  0.994 │
RenderGradient (SIMD)                                                     │    7.751 │    7.101 │    9.642 │  0.960 │
──────────────────────────────────────────────────────────────────────────┴──────────┴──────────┴──────────┴────────┘

Language: C, Optimization: -Ofast, Samples = 10, Iterations = 30          ┃ Avg (ms) ┃ Min (ms) ┃ Max (ms) ┃ StdDev ┃
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━┩
RenderGradient (Pointer Math)                                             │    3.302 │    2.865 │    5.061 │  0.693 │
RenderGradient (SIMD)                                                     │    7.607 │    6.991 │    9.923 │  0.887 │
──────────────────────────────────────────────────────────────────────────┴──────────┴──────────┴──────────┴────────┘

When Swift is compiled without the safetey checks, it's sitting right between the "Pointer Math" and the "SIMD" versions. The safety checks are causing about a 2-3 times slow-down over the -Ounchecked version though. There might be some room for improvement still in how I'm structuring things. Also, the C

I find this really exciting! We're really close to being able to write high-level, low syntactical noise code (compared to C

Again, the code for this can be found here: swift-perf. If you know any optimizatinos I should make in the C

UPDATE Friday, June26th @ 10:49 PM

Yep… so I've tracked down the issue: http://www.openradar.me/21577729. The problem is that single parameter, generic functions are implicitly turning multiple parameters into a tuple. That's the root cause of the initial bug report.

Good times.

Here's the code if you want to try it out:

func f<T>(value: T) {
    print("value: \(value)")
}

func f<T>(value: T, hi: Int) {
    print("value: \(value) \(hi)")
}

f("hi")
f("hi", append: false)
f("hi", append: false, omg: "what?")

f("hi", hi: 12)  // calls f(value: T, hi: Int)
f("hi", Hi: 12)  // calls f(value: T)

UPDATE Friday, June 26th @ 10:02 PM

OK… so I totally screwed up… It's my fault, Swift is just fine (kind-of). (I still want print() and println() back though).

SO… it turns out I have a typo in my code below in my bug report rant…

for  _ in 0 ..< titleWidth { print("━", appendNewLine: false) }
print("‚ïá", appendNewLine: false)

Should have been this…

for  _ in 0 ..< titleWidth { print("━", appendNewline: false) }
print("‚ïá", appendNewline: false)

I'll let you spot the difference. I am unsure as to why I did not get a compiler error. The only reason I noticed the issue is because I tried to workaround the issue reported below by using another overload of print(). That overload did correctly flag my labeling error. So, still a bug with print(), but no where near as bad as I originally though below.

Also, in the playground, print("hi", whateverIWant: false) works…

Anyhow, back to your regularly scheduled broadcast…

SHAME POST FOR ALL TO LEARN FROM…

I'm just going to copy my bug report here as I think this is worthy of being shared more broadly…

Bug Report First of all, I'm sure this bug has been logged before, but I don't care because this is so flipping irritating right now.

A "systems language" that has no proper ability to write console apps and output text to the screen succinctly is just broken. The move to replace print() and println() with a single function print() with an overload – terrible decision.

Ok… breathe… I can deal, it's just an overloaded function now, no problem…

Imagine your surprise when you try and use it to print out some table headers:

for  _ in 0 ..< titleWidth { print("━", appendNewLine: false) }
print("‚ïá", appendNewLine: false)

And you get output like this in the console:

("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("━", false)
("‚ïá", false)

This is retarded and completely broken. Please change print() back to the proper print() and println() versions and fix the implementation to actually output correctly to the screen.

Here's a design question for you Swifters out there.

I'm playing around with building a tokenizer that works based on a set of rules that you provide to it. From what I see, I have three basic design choices.

//
// Option 1: A tokenizer that manages its own cursor into the `ContentType`.
//
public protocol Tokenizer {
    typealias ContentType : CollectionType

    var rules: [(content: ContentType, offset: ContentType.Index) -> ContentType.Index?] { get }
    var content: ContentType { get }

    init(content: ContentType)

    mutating func next(index: ContentType.Index?) throws -> Token<ContentType>?
}

//
// Option 2: A tokenizer that passes the next index back to the user for the next call.
//
// NOTE: A tuple breaks the compiler so this type is needed: rdar://21559587.
public struct TokenizerResult<ContentType where ContentType : CollectionType> {
    public let token: Token<ContentType>
    public let nextIndex: ContentType.Index

    public init(token: Token<ContentType>, nextIndex: ContentType.Index) {
        self.token = token
        self.nextIndex = nextIndex
    }
}

public protocol Tokenizer {
    typealias ContentType : CollectionType

    var rules: [(content: ContentType, offset: ContentType.Index) -> ContentType.Index?] { get }
    var content: ContentType { get }

    init(content: ContentType)

    // HACK(owensd): This version is necessary because default parameters crash the compiler in Swift 2, beta 2.
    func next() throws -> TokenizerResult<ContentType>?
    func next(index: ContentType.Index?) throws -> TokenizerResult<ContentType>?
}

//
// Option 3: A mixture of option #1 and #2 where the tokenizer manages its own cursor location but
// does so by returning a new instance of the tokenizer value.
//
public protocol Tokenizer {
    typealias ContentType : CollectionType

    var rules: [(content: ContentType, offset: ContentType.Index) -> ContentType.Index?] { get }
    var content: ContentType { get }

    init(content: ContentType, currentIndex: ContentType.Index?)
    func next() throws -> Self?
}

Option 1

The main problem I have with option #1 is that I'm in the business of managing some bookkeeping details. This has the terrible side-effect of requiring me to expose all of the details of that bookkeeping work in the protocol so that I can provide a defautl implementation of how this works when ContentType is a String. That's bad.

The other option is to create a struct that conforms to the protocol and provides an implementation for various ContentTypes. However, I want to reserve that for a conforming type for particular structures of data, like CSVTokenizer or JSONTokenizer.

However, this option provides the benefit of being extremely easy to use as the caller of the code doesn't need to maintain the nextIndex as in option 2 or new instances of the tokenizer in option 3. Simply call next() and you get the expected behavior.

Option 2

This gets rid of all of the negatives of option #1, but it does add the burden to call the next() function with the correct index. Of course, this does allow some additional flexibility. My big concern here is the additional code that each caller will need to make each time next() is to be called. They have to unpack the optional result, then the nextIndex value and call next() with it.

Maybe this is OK. The trade-offs seem better at least. And, I can provide a default implementation for any Tokenizer that makes use of a String and String.Index.

The thing I like most about this approach is that each type of Tokenizer simple provides the rules as an overloaded read-only property.

Option 3

This kinda merges option #1 and option #2 together; it's also my least favorite. I don't like all of the potential copying that needs to be done. It's not clear to me that this will be optimized away, especially under all use cases. However, I thought I should at least mention it…

Option 4

Ok, there really is another option. It's to create a struct Tokenizer that provides an init() allowing you to pass in the set of rules to use when matching tokens. I really don't like this approach that much either. This turns handling rules for common tokenizer constructs like CSV and JSON into these free-floating arrays of rules.

That feels wrong to me. A concrete implementation of a CSV Tokenizer seems like the better approach.

Wrapping Up

I'm leaning towards option #2 (in fact, that is what I have implemented currently). It seems to be working alright, though the caller callsite is a little verbose.

guard let result = try tokenizer.next() else { /* bail */ }

// do stuff...

// Do it again!
guard let result = try tokenizer.next(index: result.nextIndex) else { /* bail */ }

This is probably ok and it's likely to be done in a loop. It just feels like a lot of syntax and bookkeeping the caller needs to deal with.

Anyhow, thoughts? Better patterns to consider?