This is awesome and I didn't know this. Thanks for posting it - I don't have much swift experience so I assume there are several things in the code that will be shown to be non-standard.

> I don't have much swift experience…

Considering the language has only been public for <36 hours, I would imagine effectively no one outside of Apple (and its Alpha partners) does.

Which will not stop recruiters from seeking candidates with 5 years experience in Swift.

What about this?

  var spawn = SKAction.runBlock self.spawnPipes

Heh. Reminds me of when I correct people for

  if var == true {...}

or (and I have actually seen this)

  if (<expression> == true) {
      return true;
  } else {
      return false;
  }

I sometimes think that simply giving those 5 lines to a person and observing if they make a face like you've handed them a bucket full of day-old fish is a better test for programming aptitude than anything.

  if var == true {...}

In some languages var might be truthy but not equal to true. The falsy values may be more of a problem at times.

However in the strongly typed swift I don't think it will be a problem as I suspect (but haven't read/tested enough yet to confirm) that only false and nil will be falsy and that comparison with true will throw errors if var isn't of bool type.

Just tried it. In Swift:

  3 == true    // Give an error (operator overload doesn't cover this)
  true == 3    // Returns false
  nil == false // Returns false

You can't use nil or integers directly in an if statement without a function to return a logic value.

Yes, such languages exist, and even in C++ if (x == true) is different from if (x), given that x is any number kind other than boolean, but my comment was only for the case when the two would be equivalent.

I'd argue the second is clearer in many cases. Readability trumps conciseness any day.

I agree that readability trumps shortness of code. I want not for APL nor code run through a javascript minifier.

But the branch and explicit boolean comparison are additional structural complexity (not just "verbosity") and invariably harms readability to me. Care give a poster child example for where it helps readability? Unless it's unclear <expression> results in a boolean - a problem better solved through better naming - code like this forces me to perform the equivalent simplification in my head to understand and reason about the code, a process fraught with error and distraction from my actual task.

Really? In which cases would the previous example be clearer than

    return expression;

What readability does the verbosity add?

Are you sure this should work? I checked the grammar once more and it seems that closure-expression should always be enclosed in { ... }