[sergejsb]

I don't have XCode to try it out, but according to the book, you can replace

  var spawn = SKAction.runBlock({() in self.spawnPipes()})

with

  var spawn = SKAction.runBlock({self.spawnPipes()})

or even

  var spawn = SKAction.runBlock() {self.spawnPipes()}

or

  var spawn = SKAction.runBlock {self.spawnPipes()}

EDIT: formatting for code

[jashmenn]

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.

[jonhohle]

> 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.

[leftcoaster]

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

[kinghajj]

What about this?

  var spawn = SKAction.runBlock self.spawnPipes

[anon4]

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.

[josephlord]

  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.

[josephlord]

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.

[anon4]

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.

[lfuller]

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

[MaulingMonkey]

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.

[the_af]

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

    return expression;

What readability does the verbosity add?

[sergejsb]

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