We recently tweeted our 20th Swift Quiz, so we thought it would be a good time to take stock and review what we've learned so far. You can find the full collection here.

The quiz is compiled every week by Ahmet Yalcinkaya, our "language design fuzzer", who does a great job exploring the edges of Swift. We look for puzzles that strike the right balance between obscurity and realism: they should illustrate a problem that might happen in everyday use, but in a way that makes you think. And of course, they must fit in a tweet!

Twitter's compactness of expression can force an extra layer of obscurity, but this isn't our aim. It also doesn't prioritize context, so it might be worth stating here: the puzzles are meant as quizzes, not whiteboard interviews questions. They're a stimulus to thought, not a test of competency.

That said, let's take a look at your answers!

The results

This graph shows the percentage of correct votes for each poll. For the most part, the success cases fluctuate around fifty percent. Which is to say that, in general, just over half of you are disposed to choose the right answer — the British might call this an "overwhelming majority".

There are some outliers, and it might be instructive to look at them more closely.

The outliers

Three quizzes left our voters stumped, despite a high turnout:

Quiz 3: Protocol Dispatch

								protocol Drawing {
    func render()
}

extension Drawing {
    func circle() { print("protocol") }
    func render() { circle() }
}

class SVG: Drawing {
    func circle() { print("class") }
}

SVG().render()

// What's the output?

/// Answers: protocol / class

							

This quiz had a 43 percent success rate, with the highest vote count.

When building an app, every once in a while you might wonder why a method doesn't get called, even though you added a specific override (like we do above, with circle). Unless the method is part of the protocol, it won't get called, because only those methods will be dynamically dispatched. Note that you can add the method to the protocol and provide a default implementation in an extension. This still allows you to override the method in a conforming type.

Quiz 20: Dictionary with Nil Values

								var dictWithNils: [String: Int?] = [
    "one": 1,
    "two": 2,
    "none": nil
]

dictWithNils["two"] = nil
dictWithNils["none"] = nil
let result = dictWithNils.count

// What’s the result?

/// Answers: 1 / 3 / Compiler Error

							

This quiz had a 30 percent success rate, with the third highest vote count.

We usually avoid dictionaries with optional values, because the behavior is confusing. The subscript used above takes an optional value, and nil means: delete this key. However, to a casual reader, this might not be obvious.

Quiz 21: Pattern Matching with Variable Values

								var x = 42

let result: Result<Int, Error> = .success(x)
x = 21

switch result {
case .success(x):
    print(x)
case .failure(_):
    print("Error")
default:
    print("Default")
}

// What’s the output?

/// Answers: 42 / 21 / Error / Default

							

This quiz had a 15 percent success rate, with the fourth highest vote count.

It's quite tricky, because it's not at all obvious what happens. The pattern match on .success(x) does not bind to the variable x, but uses the value of x to match on. In other words, it matches when result is equal to .success(21). In general, it's wise to avoid variable shadowing: don't reuse a variable name from an outer scope. Yet, there are times when matching like above is exactly what you want. To be more clear about the intent, you could rewrite it as following: case .success(let y) where y == x:. This is more verbose, but easier to spot when reading the code.

It's the taking part that counts!

Twenty two questions later, one thing becomes very clear: choosing the right answer is a lot less important than thinking through the solutions.

Perhaps the best way to learn from quizzes like this is to reflect and make your best guess, then afterwards, try the puzzle out in a playground. We tweet the solution a day after, and it can be instructive to compare our explanation with the range of analyses offered in the replies. Learning how others approach a problem can illuminate unexpected difficulties, and tell you a lot about how language users expect a language to behave.

We don’t always get the answers right either; for us, that’s what makes a question interesting. Indeed, sometimes it’s a "we didn’t know this!” moment that gives rise to a question in the first place.

If you'd like to join in with future quizzes, follow our Twitter. We try to publish every Wednesday around 4 PM Berlin.

Enjoy! 😊