There's more than a couple situations where Swift forces you to repeat yourself. No default implementations for protocols and missing language features for dealing with enums would probably be more prominent examples than this narrow availability of default arguments problem.<p>I'm not sure any one of these "work in progress" related issues are a reason to "hate Swift" (or at least, where Swift is going). It's more a reason to hate the current status of Swift as a project – since it will probably be a year or two before these sorts of non-critical issues bubble to the top of the Swift development team's priority list.
This is a very odd post. It basically boils down to default arguments only work on named functions, they don't work on function values (whether this is a curried function, or a declared value of function type). Which seems like a perfectly reasonable restriction to me; default argument values are a property of named functions, not of function types, and cannot be expressed in the type system. While it's not out of the realm of possibility for Swift to extend the type system to support this, it's not something I'd hold my breath for and it's not something I feel that I could rightly criticize Swift for not having. And yet, the author declares "Now, you hate Swift" based on this one perceived limitation.
I also ran into this problem a couple of times..<p>It's not the only issue. I put it down to how new the language is and how many non-critical issues they can fix.<p>Swift 1.2 has been a massive improvement with incremental compiling and the SourceKit HUD not flickering in my face every few minutes. But still Xcode crashes frequently.<p>With all the known problems considered, I still find that the advantage of using Swift far outweighs the small number of issues with it in its current version.